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Abstract 

We  apply  the  derivational  method  of  protocol  verification  to  key  distribution  protocols.  This  method 
assembles  the  security  properties  of  a  protocol  by  composing  the  guarantees  offered  by  embedded 
fragments  and  patterns.  It  has  shed  light  on  fundamental  notions  such  as  challenge-response  and  fed 
a  growing  taxonomy  of  protocols.  Here,  we  similarly  capture  the  essence  of  key  distribution,  authen¬ 
tication  timestamps  and  key  confirmation.  With  these  building  blocks,  we  derive  the  authentication 
properties  of  the  Needham-Schroeder  shared-key  and  the  Denning-Sacco  protocols,  and  of  the  cores 
of  Kerberos  4  and  5. 

The  main  results  of  this  research  were  obtained  in  2003-04  and  appeared  in  [3],  The  present  document 
collects  proofs  omitted  for  space  reasons  and  unpublished  background  material. 
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1  Introduction 


Key  distribution  is  one  of  the  most  studied  themes  in  security.  The  problem  and  the  basic  ideas  for  the 
solutions  were  first  described  in  Needham  and  Schroeder’s  seminal  1978  paper  [13].  On  a  network 
of  computers,  the  users  and  processes  often  need  to  access  remote  resources.  In  order  to  prevent 
unauthorized  use,  these  accesses  need  to  be  authenticated,  and  often  protected  by  encryption.  Key 
distribution  protocols  cater  to  this  need  by  providing  participating  entities  with  a  fresh  shared  key  for 
direct  and  secure  communication. 

The  most  popular  key  distribution  protocol  is  Kerberos.  It  was  designed  at  MIT,  originally  just 
to  protect  the  network  services  provided  by  Project  Athena,  an  initiative  developed  in  the  eighties 
to  integrate  computers  in  the  MIT  curricula  [18].  Distributed  for  free,  it  subsequently  achieved  a 
widespread  use  beyond  MIT.  While  its  earlier  versions  were  not  always  suitable  for  large  scale  appli¬ 
cations,  versions  4  and  now  5  have  been  redesigned  for  large  systems  [15,  16]. 

In  the  present  paper,  we  present  a  formal  reconstruction  of  the  developments  leading  up  to  the 
Kerberos  protocols.  The  starting  point  can  be  found  in  the  original  Needham-Schroeder  Shared  Key 
(NSSK)  protocol,  proposed  in  [13],  which  motivated  the  very  idea  of  the  Authentication  Server. 
Along  the  way,  the  Denning-Sacco  attack  and  protocol  [5]  championed  timestamp-based  security.1  At 
their  core,  Kerberos  4  and  5  combine  and  extend  these  ideas  into  an  industrial-strength  single-logon 
authentication  infrastructures  [15,  16]. 

We  recast  these  conceptual  steps  in  the  formal  framework  of  the  protocol  derivation  system,  that 
evolved  through  [4,  1 1],  Such  logical  reconstructions  of  development  histories  allow  classifying  pro¬ 
tocols  according  to  the  underlying  security  components  and  concepts.  The  resulting  taxonomies  then 
provide  a  foundation  for  a  practical  framework  for  secure  reasoning,  where  the  results  of  previously 
achieved  protocol  development  efforts  are  available  for  reuse,  refinement  and  composition.  One  such 
framework  is  being  implemented  as  a  tool,  the  Protocol  Derivation  Assistant,  with  all  such  recon¬ 
structions  available  as  reusable  libraries.  In  previous  work,  we  have  looked  at  electronic  commerce 
protocols  [4]  and  group  protocols  [11].  The  protocol  taxonomy  obtained  for  them  summarized  recur¬ 
rent  security  practices  and  supported  recombining  them  to  derive  further  protocols. 

Presently,  we  only  derive  the  basic  components  of  the  Kerberos  protocols  and  their  authenticity 
properties.  The  actual  deployed  protocols  chains  several  (at  least  two)  rounds  of  such  components, 
bound  together  by  secret  data.  The  issues  leading  up  to  this  composition,  and  arising  from  it,  will  be 
studied  in  a  sequel  paper. 

This  work  is  organized  as  follows:  in  Section  2  we  explain  the  protocol  derivation  infrastructure. 
We  use  it  to  express  the  basic  key  distribution  mechanism  in  Section  4.  We  extend  in  the  direction  of 
NSSK  in  Section  4  with  nonce-based  recency  and  key  confirmation.  We  extend  in  a  different  direction 
wifii  timestamp-based  recency  in  section  5  obtaining  the  Denning-Sacco  protocol  as  well  as  Kerberos 
4  and  5. 

2  Protocol  Composition  System 

We  outline  the  methodology  underlying  our  analysis  in  Section  2. 1  and  formalizes  the  resulting  frame¬ 
work,  that  we  call  the  Protocol  Composition  System ,  in  Sections  2.2-2.5.  It  should  be  noted  that, 
while  the  Protocol  Composition  System  is  clearly  inspired  by  our  previous  work  [4,  11],  a  number 

'Needham  and  Schroeder  proposed  an  alternative  fix  to  NSSK  that  does  not  rely  on  timestamps  in  [14], 
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Figure  1 :  Overview  of  the  Derivation  of  Key-Distribution  Protocols 


of  notions  are  novel.  Therefore,  the  following  material  provides  more  than  a  review  of  established 
concepts. 

2.1  Overview 

As  a  principal  A  executes  a  protocol  P,  the  events  she  observes  locally  (receiving  a  messages,  corn- 
paling  a  component  with  an  expected  value,  etc)  allow  her  to  make  deductions  about  the  actions  of 
the  principals  she  is  interacting  with.  This  implicitly  identifies  a  class  7 Za  of  possible  runs,  each  of 
which  intersperses  her  own  actions  with  compatible  actions  by  the  other  participants.  As  an  authenti¬ 
cation  property  Prop  also  identifies  a  class  72prop  of  legal  runs  for  P,  the  verification  task  traditionally 
reduces  to  showing  that  7 Za  is  contained  in  7Zprop,  and  similarly  for  the  other  parties  in  the  protocol. 
Every  run  in  7 Za  but  not  in  'Rpmp  is  an  attack  on  A  with  respect  to  Prop. 

We  take  a  different  approach:  rather  than  comparing  IZa  with  the  legal  runs  of  a  given  authenti¬ 
cation  property,  we  synthesize  a  logical  expression  4>  4  describing  7 Za-  This  explicit  representation  is 
carefully  engineered  to  be  compositional:  we  dissect  .4’s  observations  into  elementary  components 
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and  give  a  logical  representation  of  the  property  they  each  realize  (their  raison  d’etre  in  a  protocol). 
We  similarly  give  a  logical  justification  of  the  various  mechanisms  that  allow  combining  components 
into  bigger  protocol  fragments,  and  in  particular  of  what  properties  emerge  from  the  properties  of  the 
parts.  By  iterating  this  process  all  the  way  to  ,4’s  original  observations,  we  derive  a  formula,  <b  4 ,  that 
in  a  strong  sense  describes  the  properties  of  7 Za-  Indeed,  this  constructions  provides  us  with  a  clear 
view  of  the  properties  contributed  by  each  component  and  whether  they  propagate  to  4>  1 .  We  often 
restrict  our  attention  to  interesting  scenarios  by  assuming,  for  example,  that  other  principals  behave 
honestly,  or  that  a  certain  key  has  not  been  compromised.  Note  that  these  assumptions  are  elective. 

Rather  than  checking  that  a  protocols  satisfies  a  given  property  Prop,  our  approach  enumerates 
the  properties  supported  by  a  protocol  based  on  its  construction.  Whenever  an  expected  property  is 
not  manifested,  we  can  rapidly  point  to  a  missing  component  or  a  composition  mechanism  failing 
to  propagate  it,  and  produce  a  counterexample,  as  done  in  [11].  We  can  also  scrutinize  the  formula 
<l>  \  summarizing  the  possible  runs  of  each  principal  A  in  the  light  of  a  well-known  authentication 
property,  such  as  matching  histories  [6]  or  agreement  [10].  We  do  not,  however,  formalize  traditional 
properties  Prop  as  formulas  in  our  logic  for  formal  comparison  with  the  deduced  formulas  T  4  (this 
will  be  for  another  paper). 

A  crucial  aspect  of  our  approach  is  that  component-formulas  pairs  can  be  reused  whenever  they 
occur  in  another  protocols.  Even  more  interesting  is  the  fact  that  the  composition  operations  for 
fragments  and  properties  can  be  made  systematic,  which  gives  rise  to  protocol  taxonomies  [4]:  a 
rational  classification  of  protocols  that  not  only  aides  our  understanding  of  these  complex  objects,  but 
also  helps  choosing  or  devising  a  protocol  based  on  desired  features  and  properties.  We  are  working 
on  a  tool  that  will  assist  us  building  taxonomies  that  are  much  larger  than  what  we  have  so  far  been 
able  to  construct  by  hand. 

Below,  we  give  the  necessary  definitions  to  formalize  the  notions  leading  to  the  set  of  possible  runs 
7 Za  deducible  by  a  principal  A  and  the  corresponding  formula  Ty  We  define  the  basic  vocabulary 
of  terms,  actions  and  protocol  specifications  in  Section  2.2.  We  introduce  dynamic  concepts  such 
as  runs  and  observations  in  Section  2.3.  Section  2.4  sets  the  stage  for  the  logical  expression  of  the 
set  of  possible  runs  deducible  from  an  observation,  while  Section  2.5  provides  the  logical  means  to 
perform  such  deductions.  The  remainder  of  this  paper  will  apply  these  definitions  in  the  study  of  key 
distribution  protocols,  starting  from  basic  concepts  all  the  way  to  Kerberos. 

2.2  Syntactic  Categories 

In  this  section,  we  present  the  formal  syntax  used  in  the  Protocol  Composition  System.  In  particular, 
we  define  principals,  terms,  patterns,  actions,  roles  and  protocols.  These  notions  will  be  used  in  the 
sequel  to  define  dynamic  notions  such  as  runs  and  local  observations,  and  deductive  reasoning  will 
operate  on  them. 

Principals  We  model  principals  as  a  partially  ordered  set,  or  poset,  (W,  <s),  where  VV  enumerates 
the  principals  we  arc  working  with  and  the  subprincipal  relation  d  is  a  reflexive  partial  order  on  them. 
The  subprincipal  relation  can  represent,  as  needed,  access  to  information  or  resources,  or  subsume 
e.g.  the  relations  “speaks  for”  [1,  9],  or  “acts  for”  [12],  or  model  groups  and  coalitions  of  principals. 
We  will  make  limited  use  of  this  relation  in  this  paper.  We  denote  the  class  of  variables  ranging  over 
principals  with  Varyy.  We  write  A,B,S,...  for  generic  principals,  and  use  capital  letters  towards  the 
end  of  the  alphabet  for  elements  of  Varyy. 
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Terms  The  set  T  of  terms  is  an  abstract  term  algebra  constructed  over  a  set  of  variables  Var-j- 
and  a  set  of  operators  0pT  (some  of  which  may  be  constants).  Principals  arc  a  subclass  of  terms, 
i.e.  W  T  (and  similarly  for  principal  variables).  We  also  assume  the  standard  classes  used  in 
modeling  cryptographic  protocols:  Nnc,  Key,  Time  . . .  >  T  for  nonces,  keys,  timestamps,  and  so 

on.  We  write  m  for  a  generic  message,  but  use  k,  n,  t,  etc,  for  keys,  nonces,  timestamps  and  other 
specialized  messages.  The  letters  x,  y,  z,  ...  will  denote  variables.  In  this  paper,  we  will  rely  on  two 
specific  constructors: 


_  _  :  Key  xT-rT  (km  is  the  encryption  of  m  with  k) 

_:T  x  T  — >  T  (m,  m!  is  the  concatenation  of  m  and  m!) 

but  T  may  contain  more.  The  standard  subterm  relation  C  endows  terms  with  the  structure  of  a  poset 

C*M=).  ' 


Patterns  A  pattern  is  a  term  p  together  with  a  list  of  distinguished  variables  x  occurring  exactly 
once  in  p  that  will  be  interpreted  as  binders  —  p  may  contain  other  variables.  We  mnemonically 
write  this  pattern  as  p(x)  but  will  often  keep  x  implicit  when  clear  from  the  context.  The  set  Vr  of 
patterns  on  T  is  therefore  defined  as 


VT  =  IJ  (T  x  Var^) 

raSN 

We  further  restrict  the  class  of  admissible  patterns  to  account  for  non-invertible  cryptographic  opera¬ 
tions:  for  example,  we  reject  patterns  of  the  form  “x  m”  which  would  allow  extracting  the  key  used 
to  encrypt  the  term  m. 

Actions  Principals  participate  in  a  protocol  by  performing  atomic  actions.  The  set  S  of  actions  is 
generated  from  the  set  of  terms  T  and  the  set  of  principals  VV  by  the  following  constructors: 


Action 

Constructor 

Form 

Informal  meaning 

send 

TxW2mE 

(m  :  A  — >  B) 

The  term  m  is  sent,  purportedly  from 
A  to  B 

receive 

Varx  x  Var^y  •—r  S 

(x:Y-rZ) 

A  term,  source  and  destination  are  re¬ 
ceived  into  the  variables  x,  Y,  and  Z 

match 

T  x  TV  <4  £ 

(' m/p(x )) 

The  term  m  is  matched  with  the  pat¬ 
tern  p(x),  binding  x 

new 

Var r  E 

(u  x) 

A  fresh  value  is  created  and  stored  in 

the  variable  x 

now 

Var r  E 

(tx) 

The  system  time  is  read  and  stored  in 
the  variable  x 

These  actions  will  take  the  center  stage  in  this  paper.  We  will  occasionally  introduce  internal  actions  to 
model  protocol  specific  operations  (e.g.,  looking  up  an  internal  table).  Other  actions  can  be  added  as 
needed.  The  variables  x,  Y.  Z  in  receive,  x  in  match,  and  x  in  new  and  now  arc  binding  occurrences, 
so  that  any  subsequent  mention  in  an  expression  involving  actions  (e.g.,  roles  below)  arc  interpreted 
as  bound  by  them.  We  adopt  the  standard  definitions  of  free  and  bound  variables  in  an  action.  We 
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will  often  use  partial  descriptions  of  actions,  and  elide  e.g.,  the  source  and  the  destination,  as  in  (m), 
or  (y),  or  other  parts,  as  in  (A  —>  C),  or  (x  :  A  — >). 

We  will  formalize  the  meaning  of  these  actions  in  the  next  section,  where  we  present  the  execution 
model  of  the  Protocol  Composition  System. 

Roles  A  role  is  the  complete  code  that  a  principal  executes  on  her  host  to  engage  in  a  given  protocol. 
We  model  a  role  as  a  collection  of  actions  performed  by  a  principal.  We  allow  actions  to  be  composed 
either  sequentially  (using  as  a  role  constructor)  or  concurrently  (using  “<g>”).  The  set  7 Z  of  roles  is 
then  defined  as  7 Z  =  VV  x  where  the  second  component  is  the  algebra  stemming  from  E  and 

operations  and  “(g)”.  We  tacitly  use  as  an  associative  operator,  while  “g>”  will  be  viewed  as 
associative  and  commutative. 

Sequential  composition  orders  the  actions  in  a  role,  while  “g>”  specifies  clusters  that  can  be 
executed  in  parallel.  A  binder  occurring  in  an  action  has  scope  over  the  actions  in  all  paths  stemming 
from  it.  Care  should  be  taken  so  that  no  variable  is  in  the  scope  of  more  than  one  homonymous 
binder  when  disambiguation  is  not  possible:  we  avoid  this  problem  completely  by  requiring  that  every 
binder  uses  a  different  variable  name.  The  free  variables  of  a  role  arc  its  parameters,  and  should  be 
instantiated  prior  to  executing  the  role.  The  principal  executing  the  role  is  a  distinguished  parameter. 

As  an  example,  we  show  the  server  role  of  the  Denning-Sacco  protocol,  further  explored  in  Sec¬ 
tion  5: 

DSServer\S ]  =  (mo  :  A  — >■  50);  (So/S);  (mo/ A,  B)-, 

(get  Key  (A,  KAS )  g>  getKey  (B,  I\BS )); 

(u  k  g>  t  t)\ 

(. KAS(B,k,t,KBS(k,A,t ))  :  S  — >  A) 

This  role  has  one  parameter,  the  name  of  the  server  S  executing  it.  With  the  actions  on  the  first  line, 
S  receives  a  message  mo,  purportedly  from  some  principal  A  (this  is  the  binding  occurrence  for  this 
variable),  he  verities  that  he  was  indeed  the  intended  recipient,  and  that  mo  is  a  pair  with  A  as  its  first 
component  (this  occurrence  is  in  the  scope  of  the  A  in  the  receive  action)  and  some  name  B  as  its 
second  component.  The  second  line  invokes  some  internal  actions  to  retrieve  the  keys  S  shares  with 
A  and  B,  and  bind  them  to  the  variables  KAS  and  KBS  respectively.  Notice  that  this  specification 
allows  the  concurrent  execution  of  these  two  actions.  On  the  third  line,  S  generates  a  key,  binding  it  to 
k,  and  looks  up  the  current  time  into  t,  again  concurrently.  The  last  action  sends  the  shown  message. 

Protocols  A  protocol  is  a  collection  of  roles  that  covers  the  actions  of  all  parties  involved  in  the 
protocol.  In  the  case  of  Denning-Sacco,  the  protocol  consists  of  three  roles:  the  above  server  role,  an 
initiator,  and  a  responder. 

2.3  Execution  Model 

This  section  defines  the  dynamic  concepts  of  runs  and  local  observations.  We  start  with  the  prelimi¬ 
nary  notions  of  processes  (a  minimally  connected  collection  of  actions),  then  associate  every  receive 
action  with  a  send  action  in  the  notion  of  run,  then  target  the  proper  instantiation  of  variables  by 
defining  execution,  and  finally  distill  the  local  observation  of  principal  from  an  executable  run. 

Events  An  event  associates  an  action  to  a  principal,  that  we  will  understand  has  having  executed 
this  action.  We  denote  an  event  by  subscripting  the  action  with  the  principal  in  question,  writing  for 
example  (m  :  A  — >  B)a  for  the  event  of  principal  A  performing  the  action  (m  :  A  — ►  B). 
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Processes  A  process  is  a  partially  ordered  multiset  (pomset)  of  events,  i.e.,  actions  attributed  to 
principals.  More  precisely,  given  a  set  of  action  labels  L,  a  process  L  is  an  assignment 

L  =4SxW 


such  that 

•  (L,  <)  is  a  well-founded  partial  order. 

•  £  <  £'  implies  Lw(£)  <e  Lyv(f')  or  Ly^(£)  =>  Lyy(£ ')• 

where  Lyy(T)  is  the  name  of  the  principal  in  event  L(£). 

The  relation  <  orders  the  events  in  a  process  so  that  one  event  can  be  described  as  occurring 
before  another  in  an  abstraction  of  the  temporal  dimension  of  execution.  Events  that  are  not  related 
by  <  can  have  occurred  in  arbitrary  order.  The  first  condition  simply  prevents  cycles. 

The  second  condition  specifies  that  only  actions  pertaining  to  the  same  principal,  or  one  of  its 
sub-/super-principals,  can  be  ordered  in  this  way  (we  will  extend  this  ordering  across  principal  cliques 
shortly).  Like  strands  [8],  related  events  in  a  process  pertain  to  a  single  principal  (or  group  of  related 
principals).  Unlike  strands,  processes  are  not  bound  to  a  single  protocol  execution,  but  may  order 
events  executed  by  a  principal  in  several  instances  of  the  same  protocol,  possibly  in  several  roles,  and 
even  while  executing  several  different  protocols.  The  idea  is  that  a  principal  will  know  in  what  order 
she  has  executed  actions,  even  when  several  protocols  are  involved.  However,  notice  that  the  events 
of  a  principal  do  not  need  to  be  totally  ordered:  events  can  be  unrelated  if  their  exact  order  does 
not  matter,  or  if  the  underlying  execution  model  is  actually  parallel.  Finally,  processes  may  contain 
variables  bound  by  new,  receive  and  match  actions,  while  strands  arc  always  ground. 

In  the  sequel,  processes  and  related  notions  will  generally  arise  out  of  instantiated  protocol  roles. 
This  will  always  be  the  case  when  reasoning  about  the  observations  of  a  principal,  or  when  assuming 
that  a  principal  is  honest.  However,  the  actions  attributed  to  a  principal  that  is  not  assumed  to  be 
honest  may  live  outside  of  any  role. 

Before  moving  on,  a  few  notational  conventions  will  prove  enormously  helpful.  We  will  often 
abuse  notation  and  denote  a  label  £  £  L  in  a  process  L  by  the  event  L(£)  it  points  to.  Furthermore, 
we  will  often  speak,  for  example,  of  “the  event  (m  :  A  — >  B)a”  in  the  context  of  a  process  L, 
although  there  may,  of  course,  be  several  events  of  this  form  in  L.  We  will  resurrect  labels  only  in 
case  of  ambiguity.  We  will  also  sometimes  blur  the  distinction  between  an  action  and  an  event  when 
the  associated  principal  can  easily  be  reconstructed,  and  speak  of  “the  event  (m  :  A  —>  B)”  for 
example.  Finally,  we  will  make  liberal  use  of  the  convention  of  dropping  parts  of  an  action  that  can 
be  reconstructed,  and  therefore  may  further  streamline  this  example  by  speaking  of  “the  event  (m)”. 

Several  representations  of  processes  and  derived  notions  will  prove  convenient  in  different  cir¬ 
cumstance.  Of  course,  a  process  is  a  directed  acyclic  graph  (DAG)  with  events  as  nodes  and  <  as 
edges.  Here  is  a  simple  example: 


(vy)A' - ^  {f(x,y))A' 


(vx)A - [z)A - (f(x,  y))A 

(u)b 
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where  the  arrows  flow  in  the  opposite  direction  of  <  and  we  assume  A'  <s  A.  We  will  sometimes 
explicitly  render  the  ordering  <,  obtaining 


(vx)A  < 


iyy)A'  <  {f{x,y))A> 

(z)a 


<  (f(x,y))A 


(«) 


B 


for  the  above  example.  Finally,  we  will  occasionally  use  the  conventions  outlined  in  Section  2.2  to 
express  roles,  rendering  <  as  and  using  “(g)”  to  denote  the  absence  of  an  ordering.  The  above 
example  takes  the  following  succinct  form: 


((vx)A\  {{(vy)A'\  (f(x,  v))a')  <8>  {z)a)\ (f(x,  v))a)  ®  ( u)B 


It  should  be  noted  that  not  every  DAG  can  be  expressed  in  either  of  the  last  two  nota¬ 
tions  (unless  one  is  willing  to  repeat  nodes,  which  would  clash  with  our  conventions). 
For  example,  the  DAG  at  right  cannot  be  rendered  in  these  ways. 


b 

d 


Runs  A  run  of  a  process  L  assigns  to  each  of  its  receive  events  a  corresponding  send  event.  For¬ 
mally,  a  run  is  thus  a  pair 


(L,  \J  :  recvs(L)  — >  sends(L)) 

(x:Y—>Z)a  !->•  (m:S^R)B 

such  that 

y/(x)  ?  (x) 

The  condition  forces  the  send  event  mapped  to  a  receive  event  to  have  occurred  before  this  event.  It 
prevents  deadlocks,  and  protects  the  scope  of  the  receiving  variables  (which  is  to  the  right,  i.e.,  up  in 
the  partial  order). 

A  run  can  also  be  viewed  as  an  extension  of  the  order  <  of  events  in  a  process  by  adding  V(x)  < 
( x )  for  every  receive  action  (x)  €  L.  We  shall  thus  represent  a  run  (L,  \J)  simply  by  a  process  L 
where  each  receive  event  (x)  has  a  unique  predecessor  (m)  =  \J (x).  A  run  of  a  process  thus  boils 
down  to  a  Lamport  order  of  actions.2 

We  pointed  out  earlier  that  a  process  corresponds  to  a  collection  of  strands.  In  the  same  vein,  a 
run  is  akin  to  a  bundle  in  the  strand  world  [8],  The  main  difference  between  our  runs  and  bundles  is 
that  in  the  present  framework,  the  variables  can  be  used  to  follow  the  execution  of  the  run,  and  track 
the  data  as  it  flows  through  it.3 

2This  is  in  contrast  with  the  representation  of  runs  as  process  reductions  a  la  Chemical  Abstract  Machine,  used  in  the 
cord  calculus  [4,  7]. 

3If  in  a  bundle  a  principal  receives,  say,  the  number  2,  and  then  sends  out  the  number  3,  it  is  impossible  to  tell  whether 
his  program  says  to  receive  x  and  then  send  x  +  1,  or  to  send  2a:  —  1,  or  perhaps  to  send  3  independently  on  what  he 
receives. 
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Execution  The  above  definition  falls  short  of  capturing  the  intuitive  notion  of  a  run  as  a  snapshot  of 
the  execution  of  a  protocol.  Indeed,  while  our  runs  correctly  map  receives  to  sends,  they  do  not  ensure 
that  variables  arc  properly  handled.  In  particular,  they  allow  events  to  take  place  past  a  failed  match. 
Rather  than  giving  syntactic  restrictions  to  characterize  a  well-formed  executable  run,  we  keep  our 
runs  the  way  they  arc  and  define  a  notion  of  execution  on  them. 

A  slice  (L<,L>~)  is  an  order-conscious  partition  of  a  run  (L,y/),  i.e.,  for  every  l\  £  /A  and 
I2  £  Ly,  it  is  not  the  case  that  h  <  h-  Every  path  in  L  will  have  a  prefix  in  /A  and  the  rest  in  LA  We 
mark  the  meeting  point  with  T . 

Executing  a  run  will  consist  of  moving  the  markers  T  rightward  starting  from  an  initial  slice  (0,  L) 
where  there  is  a  marker  at  the  beginning  of  every  path.  The  events  in  a  run  are  executed  in  order:  each 
a  £  L  can  be  executed  only  after  all  b  <  a  have  been  executed.  Execution  on  any  given  path  is 
specified  by  the  following  table: 


Action 

Form 

If... 

. . .  then  do  . . . 

. . .  and  write 

send 

T(m  :  A  ->  B)c 

FV  (m)  =  0 

(to  :  A  — >  B)q 

receive 

y(x:Y->Z)D 

V(x  :  A  -  Z)D 
=  {m:  A— r  B)c 

in  all  a  >  (x  :  Y  — >  Z)p  set 
a(x  :=  m,  Y  :=  A,  Z  :=  B) 

{x-.y^  zyD 

match 

y(m/p(x))D 

3 U  S.t.  TO  =  p(u) 

in  all  a  >  ( m/p(x ))  set  a(x  :=  u) 

(m/p(x)yD 

. . .  otherwise  . . . 

. . .  halt  on  this  path 

J(m/p(x))D 

new 

tWd 

iyx)i 

now 

j{tx)d 

(tx)d 

Note  that  execution  on  a  path  will  stop  when  a  match  fails.  It  can  however  proceed  on  other  paths. 


Remark  1  In  principle,  a  run  all  of  whose  actions  have  been  successfully  executed  records  all  of 
the  executed  assignments.  This  distinguishes  the  computational  assignment  operation  x  :=  mfrom 
the  algebraic  substitution  operation  ( m/x ).  When  substituting  m  for  a  variable  x  in  a  term  a,  we 
simply  replace  the  occurrences  of  x  by  m;  the  result  a(m/x)  generally  bears  no  trace  of  x  (unless  it 
occurred  in  rn).  In  contrast,  when  assigning  m  to  x,  we  link  x  to  m,  thereby  destroying  any  previous 
links  of  x,  yet  we  do  not  erase  the  name  of  x  itself  Indeed,  in  computation,  x  can  later  be  reassigned 
to  another  term  ml. 

When  executing  a  run,  the  variables  are  assigned,  but  not  destroyed.  In  this  way,  the  dataflow  of  a 
run  is  completely  recorded,  since  each  binding  actions  just  performs  assignments  on  some  previously 
unassigned  variables. 

Executable  Runs  The  left  component  I/'  of  a  slice  ( /A ,  /A )  of  a  run  (L,  \J)  satisfies  the  intuitive 
notion  of  run  as  a  snapshot  of  the  execution  of  a  protocol.  We  adopt  it  as  the  definition  of  an  executable 
run ,  and  will  denote  such  entities  with  the  letter  Q,  variously  annotated.  From  now  on,  all  the  runs 
we  will  be  working  with  will  be  executable  and  we  thus  will  generally  drop  this  qualifier. 

Local  Observations  The  local  observation  of  a  principal  A  consists  of  all  the  events  performed  by 
A  in  a  run  Q.  It  is  simply  defined  as  the  projection  of  Q  with  respect  to  A  together  with  the  binding 
of  all  mentioned  variables: 


Qa  —  {!  £  Q  |  Lyy(t')  —  A} 


2.4  Logical  Annotations 


Having  defined  the  notions  of  (executable)  run  and  observation,  we  will  now  define  a  logical  language 
to  talk  about  these  entities.  This  language  applies  the  connectives  and  quantifiers  of  first-order  logic 
to  a  base  set  of  predicates.  We  will  then  be  able  to  define  a  judgment  that  verifies  that  a  formula 
constructed  in  this  way  is  valid  with  respect  to  a  run.  It  will  then  be  a  short  step  to  use  a  formula  to 
characterize  all  the  runs  in  which  it  is  valid,  and  to  anchor  it  to  the  local  observations  of  a  principal. 


Predicates  Our  logical  language  contains  just  enough  tools  to  query  a  run:  the  event  predicates  we 
will  be  relying  on  arc 

a  Event  a  has  occurred 

a  <  h  Event  a  has  occurred  before  event  b 

a  =  b  a  and  b  are  the  same  event 


We  will  also  admit  the  various  relations  participating  in  the  definition  of  principals  (e.g.,  A  <e  B ), 
terms  (e.g.,  m  C  m!),  etc,  as  additional  predicates.  A  formula  combines  these  atomic  predicates  by 
means  of  the  traditional  connectives  and  quantifiers  of  first-order  logic.  We  will  allow  quantification 
over  terms  and  principals  appealing  in  an  event,  and,  with  a  slight  abuse  of  notation,  over  events 
themselves. 

Formulas  can  be  used  to  describe  runs  or  portions  of  runs:  simply  turn  a  pair  of  connected  events 
“a  — >  b”  into  the  atomic  predicate  a  <  b,  add  the  occurrence  predicate  a  for  any  isolated  event  “a”, 
and  glue  them  together  with  A.  We  write  for  the  formula  obtain  in  this  way  from  a  run  Q.  For 
example,  the  following  formula  captures  the  first  few  steps  of  an  instance  of  the  Denning-Sacco  server 
role  from  Section  2.2  for  a  given  server  S: 

(m0  :  A  -  S0)s  <  (S0/S)s  A  (S0/S)s  <  (mo/ A,  B)s 
A  (mo /A,  B)s  <  getKey(A,  KAS)S 
A  (mo /A,  B)s  <  getKey (B,  KBS)S 

A  getKey  (A,  K AS)S  <  (v  k)s  A  getKey  (A,  ICAS)S  <  (r  t)s 
A  getKey (S,  KBS)S  <  (v  k)s  A  getKey(H.  I<BS)S  <  (r  t)s 


An  automated  theorem  prover  can  make  use  of  this  formula,  but  it  looks  rather  obscure  to  a  human. 
For  this  reason,  we  will  rely  on  generous  notational  conventions  and  express  it  in  the  more  readable 
format: 


(A,B:A^S)s< 


getKey  (A,  KAS)S 

AT’ 

Co 

— i 

getKey (B,  KBS)S_ 

,(Tt)sm 

The  following  table  lists  some  of  the  least  obvious  abbreviations  we  use: 


This  . . . 

. . .  abbreviates  . . . 

Notes 

(. p)a 

(x)a  <  ( x/p)A 

Binders  in  p  usually  implicit 

Ma 

(x)a  <  (x/p')AAp  C  p’ 

Same  binders  in  p  and  p' 

(M)a 

(m!)  a  A  m  C  77?/ 

(m)A< 

3a  =  (rn)A  A  V6  =  ((m))#.  a  <  b 

where  B  is  arbitrary 

((™))a< 

3a  =  ((m))A  A  Mb  =  ((m))s-  a  <  b 

where  B  is  arbitrary 

a  -<b 

b  =^>  a  <  b 

Especially  in  logical  statements,  we  will  often  omit  the  intended  sender  and  recipient  in  a  send  or 
receive  action  when  unimportant  or  easily  reconstructible  from  the  context. 
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Validation  Given  a  run  Q  and  a  formula  <b,  a  first  task  is  to  verify  if  $  is  valid  in  Q.  We  express 
this  classical  model  checking  problem  by  means  of  the  judgment 


[Q]* 

where  Q  is  ground  and  <f>  is  closed.  As  usual,  the  definition  of  validity  is  inductive,  with  the  following 
table  expressing  the  validity  of  our  basic  event  predicates: 


Predicate 

Judgment 

If  and  only  if 

Meaning 

event 

[Q]  a 

a  G  Q 

a  has  occurred  in  Q 

order 

[Q]  a  <  b 

a  <  b  G  Q 

a  has  occurred  before  b  in  Q 

equality 

[Q]  a  =  b 

a  and  b  are  the  same  event  in  Q 

The  relational  predicates  on  terms  and  principals  arc  self-validating.  The  logical  connectives  and 
quantifiers  arc  processed  in  the  usual  way. 

Statements  If  only  a  formula  $  is  given,  the  above  judgment  can  be  used  to  implicitly  define  the 
set  of  all  the  runs  that  satisfy  <[>; 

K®  =  {q  :  [q\ 

In  particular-,  if  <h  describes  the  observations  0  a  of  a  principal  A  in  a  given  run  Q,  a  formula  we  wrote 
<1>qa  earlier,  the  above  definition  allows  us  to  characterize  all  the  runs  q  that  are  compatible  with  QA : 


HA  =  {q:  [q]  $qA} 

While  this  satisfies  the  requirement  at  the  beginning  of  this  section,  expressing  7 ZA  in  this  way  sheds 
little  light  on  the  structure  that  a  run  must  have  to  be  compatible  with  A’s  observations.  In  the 
next  section,  we  will  instead  strive  to  explicitly  characterize  these  runs  by  means  of  a  formula  <[>  of 
maximal  generality.  <[>  will  be  such  that: 

nA  =  {q-  [q\  $qa}  =  {q  :  [q]  d>QA  A  $} 

We  will  generally  keep  <I>qa  explicit  by  expressing  <b  as  the  logically  equivalent  Tq,  =>•  (<I>q4  A  (I> ) . 

We  will  deduce  this  formula  from  the  axioms  and  inference  rules  described  in  the  next  section  to 
get  as  clear  a  picture  as  possible  of  7 ZA.  By  having  <b  be  an  implication  <b/  =>•  we  can  chai-acterize 
important  or  interesting  portions  of  7ZA  that  satisfy  the  assumption  <h/:  we  will  typically  assume  the 
honesty  of  principals  or  the  fact  that  a  key  has  not  been  compromise.  Note  that  <[>q1  =>•  (d>qA  A(<k/  => 
$"))  is  logically  equivalent  to  (Tq^  A  dA)  =>•  (Tqi  A  T").  Given  the  prominence  of  this  notion  in 
the  rest  of  our  work,  we  will  abbreviate  <I>qa  A  T  as 

A  :  $ 

<l>  is  then  a  description  of  the  runs  compatible  with  A’s  observations.  We  will  often  call  <h  the  knowl¬ 
edge  of  A.  As  we  said,  d>  will  generally  have  the  form  <I>qa  A  =>•  A  $>". 


10 


2.5  Axioms  and  Rules 


Let  A  be  a  principal  executing  the  role  p  of  a  protocol  P.  Given  a  run  Q  and  local  observation  Q  \ 
for  A’s  execution  of  p,  this  section  presents  the  tools  to  synthesize  a  formula  $  such  that  A  :  $, 
i.e.,  that  characterizes  the  runs  compatible  with  Q  \  (possibly  restricted  by  appropriate  assumptions). 
In  order  to  do  so,  we  isolate  the  elementary  constituents  of  Q,\  (for  example  challenge-response 
exchanges)  and  produce  formulas  that  describe  the  runs  compatible  with  them  (the  necessary  behavior 
of  a  counterpart  in  the  case  of  challenge -response).  We  then  combine  these  formulas  into  larger 
formulas  corresponding  to  bigger  parts  of  Qa,  all  the  way  to  Q a  itself.  An  intuitive  picture  of  this 
process  is  given  below: 


Qa  <f> 


More  precisely,  the  derivation  of  a  formula  $  characterizing  the  runs  compatible  with  a  local 
observation  Q\  draws  from  two  ingredients: 

Axioms  An  axiom  maps  an  elementary  observation  with  a  formula  expressing  the  necessary  behav¬ 
iors  of  the  interacting  parties.  Axioms  arc  universal  predications  about  basic  patterns  of  events. 
In  the  illustration  above,  the  axioms  corresponds  to  the  single  arrows  connecting  the  leaves  of 
the  trees.  We  will  spend  the  rest  of  this  section  justifying  a  number  of  common  axioms. 

Transformations  A  transformation  maps  a  method  for  building  a  complex  observation  from  simpler 
ones  to  a  method  for  upgrading  the  formulas  associated  with  them  to  a  formula  describing  the 
resulting  observation.  A  transformation  may  extend  a  partial  observation  with  additional  events, 
or  enrich  individual  events  with  new  components,  or  combine  events  by  merging  common 
terms.  We  will  see  several  transformations  in  the  sections  to  come.  Had  we  found  a  good  way 
to  draw  transformations  in  the  above  illustration,  they  would  relate  the  branches  exiting  an  inner 
node  on  the  left-hand  side  to  the  branches  entering  the  corresponding  node  on  the  right-hand 
side. 

Before  we  describe  some  of  the  most  fundamental  axioms  of  the  Protocol  Composition  System, 
a  few  definitions  will  save  us  some  space. 

Honesty  Assumption  In  the  sequel,  we  will  occasionally  need  a  principal  A  deducing  A  :  $  to 
assume  that  another  principal  B  is  honest  in  order  to  draw  interesting  or  meaningful  conclusions.  By 
this,  we  mean  that  B  does  not  deviate  from  his  assigned  role  p'  as  he  interacts  with  A.  For  the  sake 
of  illustration,  let  p'  be  completely  sequential: 

p'[B\  =  61;. 
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Therefore,  if  A  is  able  to  deduce  that  an  honest  B  has  executed  any  given  action  bt  in  this  role,  she 
can  safely  infer  that  he  has  executed  all  the  actions  leading  to  bj  in  p'  as  well.  The  resulting  formula 
for  the  above  example  is  as  follows: 

Honesty  B  =  (b1)B  ( bl)B  <  ■  ■  ■  <  ( bn)B 


(Recall  that  a  ~<  b  abbreviates  b  =>  a  <  b.)  We  will  generally  keep  the  role  p'  implicit.  Clearly, 
honesty  formulas  arc  associated  with  every  role,  not  just  the  sequential  ones.  For  example,  the  honesty 
definition  for  the  server  role  of  the  Denning-Sacco  protocol  in  Section  2.2  is  as  follows: 


{A,  B  :  A  S)s  -< 


getKey(A,  KAS)S 

J 

to 

- 1 

_getKey(B,KBS)s_ 

_(Tt)s_ 

-4 


-<  (Kas{B,  k,  t,  KBS(k,  A,  t)):S — ►  A)s 

(We  are  relying  on  the  abbreviations  in  Section  2.4  for  succinctness.) 

The  honesty  definition  will  be  used  exclusively  as  an  assumption  so  that  A  :  $  will  often  have 
the  form  A  :  Honest  B  =>•  We  will  see  that  some  principals  need  to  be  assumed  honest  for  the 
formula  inferred  from  .4’s  observations  to  be  compatible  with  the  legal  runs  of  the  protocol,  while 
other  principals  may  be  dishonest  and  yet  cannot  substantially  deviate  from  the  protocol  given  A’s 
observations. 


Uncompromised  Key  Assumption  Another  important  assumption  we  will  need  to  make  is  that 
certain  keys  have  not  been  compromised.  A  shared  key  k  is  uncompromised  for  a  group  G  of  agents 
if  the  only  principals  that  can  perform  an  encryption  or  a  decryption  using  k  are  the  members  of  G. 
In  symbols, 

uncompromised(A;,  G)  =  ((km))x<  =>•  X  G  G 

A  (x/k  y)x  a  I  6  G 

where  the  universal  quantification  over  m,  x  and  y  has  been  kept  implicit  for  clarity.  Notice  that  the 
body  of  this  definition  expresses  the  semantics  of  shared-key  cryptography:  the  first  line  says  that 
only  members  of  G  can  produce  an  encryption  using  k  and  send  it  in  a  message,  while  the  second  line 
says  that  only  these  principals  can  use  the  pattern  k  y  to  access  the  contents  of  a  term  encrypted  with 
k.  Notice  also  that  this  expression  defines  the  binding  between  a  key  and  the  principals  who  can  use 
it. 

In  this  paper,  we  will  use  uncompromised  exclusively  as  an  assumption.  Moreover,  we  will  make 
such  an  assumption  for  every  key  we  need  to  believe  is  not  compromised  as  our  system  does  not 
contain  any  axiom  explaining  how  shared  keys  ought  to  be  used. 

The  reasons  for  this  choice  are  rather  subtle  and  deserve  further  explanation.  Key  distribution  pro¬ 
tocols  juggle  two  long-scrutinized  properties:  secrecy  and  authentication.  The  distributed  key  can  be 
secret  only  if  it  is  transmitted  inside  authenticated  messages.  In  turn,  a  message  can  be  authenticated 
only  if  it  protects  its  contents  using  a  secret  key,  which  brings  us  back  to  the  problem  of  distributing 
this  secret  key.  This  is  a  chicken  and  egg  situation.  The  only  way  to  break  this  circularity  is  to  assume 
either  the  existence  of  a  shared  secret  key  or  the  existence  of  an  authenticated  channel.  We  choose 
the  first  alternative,  although  the  second  option  (e.g.,  using  a  private  communication  medium)  would 
be  equally  valid.  Assuming  certain  long-term  keys  to  be  secret  (i.e.,  uncompromised)  immediately 
yields  that  any  message  they  encrypt  are  authenticated. 
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Now,  a  key  distribution  protocol  transmits  a  freshly  generated  key  k  along  these  authenticated 
channels  to  some  principals  A  and  B.  The  next  question  becomes  how  to  prove  that  the  pro¬ 
tocol  ensures  the  secrecy  of  k,  i.e.,  that  uncompromised(k’,  [A,  5])  holds.  This  question  will  be 
the  focus  of  a  sequel  to  this  paper,  and  we  shall  not  address  it  further  here.  There,  a  proof  of 
uncom  promised  (k,  [A,  B ])  will  permit  discharging  an  assumption  of  uncompromised  (A:,  [A,  B]),  which 
is  very  useful  for  staged  protocols  such  as  Kerberos,  where  a  key  is  distributed  for  the  purpose  to  pro¬ 
tecting  another  key. 

A  number  of  authors  have  proposed  techniques  to  prove  secrecy  properties,  e.g.,  Schneider’s  rank 
functions  [17]  and  Thayer  et  aV s  ideals  [19]  just  to  cite  a  few.  At  heart,  they  arc  all  based  on  a  form 
of  closed-word  assumption  which  limits  the  class  of  available  actions  and  then  rely  on  an  inductive 
argument  to  prove  that  the  key  cannot  be  revealed.  The  present  paper  is  instead  open-ended:  all  events 
are  allowed  unless  expressly  forbidden  (e.g.,  by  an  uncompromised  assumption). 

We  will  now  discuss  a  number  of  axioms  and  axiom  schemas  that  will  provide  some  of  the  foun¬ 
dation  for  the  rest  of  the  paper. 

Freshness  axiom  We  start  with  a  general  axiom  describing  the  behavior  of  the  (y  n)  action  in 
logical  terms: 

{u  ti)b  A  a  a  =>•  (n  €  FV  (a)  =>•  (u  n)B  <  a  a 

A  (A  /  B  =>  (yn)B  <  (( n))B  <  (( n))A  <  a^))  (new) 

The  first  part  implies  that  v  is  a  binder,  which  means  that  any  event  a  mentioning  n  necessarily  occurs 
after  (y  n )  (recall  that  we  required  binders  not  to  recycle  variable  names  for  simplicity).  The  second 
line  requires  that  if  the  agent  B  executing  (y  n)  and  the  principal  A  executing  a  arc  different,  then  B 
must  have  used  a  send  action  to  transmit  n  and  A  must  have  acquired  it  by  means  of  a  receive  action; 
said  in  other  words,  values  freshly  generated  using  v  can  only  be  transmitted  using  the  send/receive 
mechanism. 

“Not  Me!”  Axiom  The  next  axiom  is  equally  general:  it  says  that  if  an  observer  A  is  aware  that 
some  X  has  executed  an  action  a,  but  A  never  executed  any  such  action,  then  X  cannot  be  A: 

A:  ax  A  ^aA  — ►  X  A  (notme) 

This  axiom  relies  on  the  fact  that  an  observer  is  aware  of  all  of  its  actions.  It  will  turn  useful,  for 
example,  in  conjunction  with  the  uncompromised  assumption  for  A  to  deduce  that  an  encrypted 
message  originated  by  the  principal  she  is  sharing  the  key  with  (and  not  herself). 

Send-Receive  Axiom  Schemas  Next,  we  examine  a  general  class  of  axioms  allowing  a  principal 
A  to  infer  the  existence  of  a  specific  send  event  matching  a  receive  she  has  observed.  They  arc  all 
subsumed  by  the  following  schema: 

AL  :  BX.Vy.  (( fAX(y)))A  A  $(X,y) 

=>  « fAX(y)))x<  <  (( fAX(y))U  A  nx,y)  (sr) 
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It  says  that  A  knows  that,  for  some  principal  X,  the  message  structure  fAX  assures  that,  if  she 
receives  a  message  containing  fAX(y),  where  X  and  y  satisfy  some  precondition  <k,  then  X  must 
have  originated  fAX(y),  and  moreover  X  and  y  do  satisfy  some  postcondition  'k. 

A  number  of  important  axioms  capturing  the  semantics  of  interaction  through  send  and  receive 
events  are  subsumed  under  this  schema,  by  instantiating  fAX,  $  and  *k.  We  will  now  examine  a  few. 

Receive  Axiom.  In  the  simplest  case,  where  <b  and  'k  are  taken  to  be  trivially  true,  and  fAX  is 
arbitrary,  the  axiom  just  says  that  everything  that  is  received  must  have  been  sent  by  someone: 

A  :  ((m))A  =>  3X.  ({m))x<  <  {{m))A  (rev) 

Challenge-Response  Axiom  Schema.  Perhaps  the  most  useful  instance  of  (sr)  is  another  axiom 
schema  describing  the  requirements  for  nonce-based  challenge-response  exchanges.  It  is  obtained 
for: 


fAX(y)  =  rAX(y) 

*(X,y)  =  <k'A  (uy)A<{{cAX(y)))A<<((rAX(y)))A 

^f(X,y)  =  (uy)A  <  ((cAX(y)))A<  <  ((cAX(y)))x  <  ({rAX(y)))x< 

where  cAX  is  the  challenge  structure  issued  by  A,  rAX  is  the  corresponding  response  originated  by  X, 
and  <b/  represents  some  additional  precondition,  usually  an  honesty  or  uncompromised  assumption. 
Simplifying  yields: 

A  :  <k'  A  (uy)A  <  « cAxy))A<  <  (( rAxy))A 

=>  (yi l)A  <  {(cAXy))A<  <  (( cAxy))x  <  {{rAxy))x<  <  (( rAxy))A  (cr) 

where  we  have  again  kept  the  existential  quantification  over  X. 

As  an  example  of  an  actual  instance  of  this  axiom,  we  consider  the  case  in  which  cAX  is  the 
identity  (the  nonce  is  sent  in  the  clear),  the  response  encrypts  the  nonce  with  a  key  KAX  shared 
between  A  and  X,  and  <k/  requires  KAX  not  to  be  compromised  for  A  and  X.  We  obtain 

A  :  uncompromised(/ij4X,  [A,  X])  A 

{vy)A  <  (( y))A<  <  (( KAxy))A 

=>  {vy)A  <  {{ v))a<  <  {{y))x  <  (( KAX  y))x<  <  (( KAX  y))A 

A  proof  of  this  axiom  goes  as  follows:  starting  from  A’s  own  observations  (the  second  line  above), 
axiom  rev  entails  that  some  agent  Y  has  originated  ((KAX  y)).  By  the  uncompromised  assumption, 
Y  must  be  either  X  or  A,  with  axiom  notme  excluding  the  latter  possibility.  Axiom  new  completes 
the  second  line  by  sandwiching  X’s  reception  of  y  between  A’s  transmission  of  the  nonce  and  X’s 
issuing  of  ((KAX  y)). 

In  the  sequel,  we  will  represent  a  run  of  this  challenge-response  exchange  by  means  of  the  fol¬ 
lowing  diagram: 

A  X 

o 

vu\ 

Y  y 

O  - s-  o 

I 

o  -< - o 

Kax  y 
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Timestamps.  Other  useful  instances  of  the  sr  axiom  schema  describe  the  semantics  of  timestamps. 
Here  is  one  possibility.  Consider  the  following  values  for  our  various  meta-variables: 

fAX(t)  =  t 
*(X,t)  =  ((t))x< 

*1 f(x,t)  =  honest  X  =>  {{rt)A  <  ( rt)x  <  ({t))X<  A  ((t))A  <  (rt)A) 

Let  us  instantiate  and  simplify  sr  before  commenting  on  it: 

A:  honest  X  A  ((t))x<  < 

=>  (rt)A  <  ( rt)x  <  {{t))x<  <  (( t))A  <  (r  t)A  (ts) 

The  antecedent  of  this  formula  assumes  that  X  is  honest  (which  here  means  that  his  expected  behavior 
is  to  look  up  a  timestamp  and  send  it  out),  A  receives  a  message  containing  an  acceptable  timestamp 
t,  and  she  has  the  certainty  that  X  has  originated  ((f)) .  Given  these  hypotheses,  she  can  deduce  that 
X  had  indeed  looked  up  t  and  sent  it  out,  and  that  these  actions  took  place  within  what  she  regards 
as  the  window  of  validity  of  this  timestamp.  Here,  (r  t)A  is  the  earliest  point  in  time  where  A  would 
accept  t  as  valid,  and  (r  t)A  is  the  dual  upperbound.  They  arc  events  internal  to  A  representing 
time  points  calculated  from  t  by  considering  what  she  deems  as  acceptable  clock  skews  and  network 
delays.  What  is  important  here  is  that  they  bound  A’’s  actions  by  events  under  ,4’s  control.  In  the 
sequel,  we  will  discharge  the  assumption  that  A  is  certain  that  X  has  sent  this  timestamp  whenever 
the  message  is  authenticated. 

Note  that  there  arc  other  options  for  giving  the  semantics  of  timestamps  as  an  instance  of  sr:  the 
above  approach  will  however  prove  particularly  convenient  in  the  sequel. 

Diffie -Heilman.  Although  we  will  not  make  use  of  this  mechanism  in  this  paper,  it  is  interesting  to 
note  that  the  sr  axiom  schema  also  specializes  to  a  crude  logical  description  of  the  Diffie-Hellman 
exchange  (where,  for  simplicity,  we  have  the  responder  transmit  the  shared  secret  in  some  message). 
We  instantiate  the  various  schematic  variables  as  follows: 

fAX{g,u,y)  =  uy 

®(X,  g,  u,  y)  =  {u  y)A  <  { gy)A<  <  (u)A  A  ~'{y)A 
^{X,g,u,y)  =  (u)x<  A  (-.(logw)x  =>  (. gy)x  <  (( uy))x< ) 


for  appropriate  term  constructors  for  exponentiation  and  discrete  logarithm.  Here  g  is  the  group 
generator,  y  is  .4’s  random  number,  u  is  X’s  returned  value  (u  =  gz  where  z  is  X's  random  number), 
and  therefore  u!J  =  gyz  is  the  shared  secret.  Simplifying  and  rearranging  this  time  yields: 


A:  —>(y)A  A  -■(log  u)z 


(vy)A  <  ( 9v)a< 


< 


=>  3X.  ( uy)A  <  (gy)A<  <  (gy)x  < 


(u)x< 

,((uy))x< 


(u)a 

(iuy))A 

(“)a 

(Ma 


(dh) 


This  formula  states  that  if  A  receives  her  counterpart’s  share  of  the  secret  and  a  message  containing 
the  secret,  and  neither  exponent  has  been  leaked,  then  she  can  rest  assured  that  some  X  has  received 
her  own  gy  and  send  those  two  messages. 
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3  Basic  Key  Distribution 

In  this  section,  we  apply  the  methodology  just  outlined  to  obtain  the  core  protocols  and  logical  guar¬ 
antees  for  key  distribution.  For  the  time  being,  we  arc  only  interested  in  the  manner  a  key  server  can 
distribute  a  fresh  key  to  clients.  We  will  examine  other  important  aspects  of  key  distribution,  namely 
recency  and  key  confirmation,  in  Sections  4  and  5,  where  we  derive  NSSK  and  Kerberos,  respectively. 

We  warm  up  in  Section  3.1  with  an  illuminating  exercise  in  futility:  having  a  server  distribute 
a  fresh  key  to  a  single  principal.  We  take  it  as  a  template  for  the  more  useful  two-client  setting  in 
Section  3.2. 

3.1  One-Party  Key  Distribution 

We  begin  with  a  very  simple  setup  consisting  of  a  key  server  S  and  one  client  A.  While  the  resulting 
protocol,  which  distributes  a  secret  key  to  a  single  principal,  makes  little  sense  in  practice,  it  will  serve 
as  a  useful  illustration  of  the  concepts  introduced  so  far  and  help  gain  familiarity  with  transformations. 
Later,  when  applying  these  techniques  to  more  realistic  protocols,  we  will  be  able  to  concentrate  on 
the  derived  properties  rather  than  on  minor  technicalities. 

In  our  initial  version  of  this  protocol,  both  the  key  server  and  the  client  arc  given  each  other’s 
name  as  a  parameter  to  their  respective  roles.  A  fully  spelled-out  specification  of  these  roles  is  as 
follows: 

KD^  .server  [S';  A]  =  get  Key  (A,  KAS)  •  is  k  ;  (KAS  k  :  S  — >  A) 

KD°_client[A;  5]  =  (m0  :  50  -  A0)  ;  (A0/A)  ;  (S0/S)  ; 

getKey (S,Kas)  ;  (mo/KAS  k) 

(We  will  abbreviate  it  shortly.)  The  server  “knows”  it  should  send  the  new  key  k  to  A  because  A 
appeal's  in  its  parameter  list. 

A  process  involving  one  instance  of  each  of  these  roles  is  given  by  the  nodes  and  solid  lines  in  the 
graph  below  (please  ignore  everything  else  for  now).  We  have  written  A  and  S  for  the  instantiating 
values  of  the  parameters  A  and  S,  and  distinguished  binders  with  the  same  name  in  the  two  roles  by 
means  of  primes.  The  expected  run  of  this  protocol  bridges  these  two  halves  by  means  of  the  dashed 
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arrow. 


getKey(A,  KAS)$ 

I  {Kas:= kAS} 


(m0  :  So  A0)a 

fc,S0:=S,A0:=A} 

Y 

(4,/A)a 

(S0/S)A 

Y 

get  Key  (S,  K'AS)A 

{...,A"AS:=kAS} 

Y 

(m0/K'AS  k')A 

{...,kr’.=k}y 


(^)s 


I 

(IiAS  A:  :  S  A)s 


Another  expression  for  this  process  is 

getKey(A,  K- AS)  \vk\  (KAS  k  :  S  -»•  A) 

<g)  (m0  :  So  — ►  A0)  ;  (A0/A)  ;  (So/S)  ;  getKey(S,  K'AS) ;  (m0/K,AS  k') 

The  run  assigns  yj (mo  :  ^o  — >  Ao)a  =  (A'5"4  k  :  S  — >  A)$. 

An  execution  of  this  run  accumulates  binding  variable  assignments  in  an  environment  that  we 
have  expressed  above  as  annotation  to  the  arrows.  By  the  time  the  last  action  has  been  executed,  this 
environment  contains: 

{Kas  :=  kAS,  m0  :=  KAS  k,  S0  :=  S,  A0  :=  A,  K,as  :=  kAS,  k'  :=  k} 

By  the  end  of  this  run,  the  observations  Q A  and  Qs  of  A  and  S  correspond  to  the  left  and  right  column 
of  the  above  figure,  respectively. 

While  we  hope  this  demonstrated  the  definitions  in  Section  2.3,  the  remainder  of  this  paper  will 
use  a  leaner  notation  based  on  the  conventions  introduced  in  the  previous  section.  This  will  make  our 
treatment  more  readable  and  save  space.  In  particular,  we  will  liberally  fold  matches  inside  receive 
actions,  occasionally  omit  senders  and  receivers,  and  keep  the  internal  actions  getKey  implicit.  The 
roles  in  this  example  then  reduces  to: 

KD?_server[A;  A]  =  v  k  ;  (KAS  k  :  S  -»•  A) 

KD?_client[A;5]  =  (KAS  k  :  S  A) 
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We  also  summarize  the  above  run  in  the  following  strand-like  picture: 


5 

o 

| uk 
O 

We  arc  now  ready  to  take  the  point  of  view  of  each  principal  and  infer  a  formula  representing 
the  runs  that  arc  compatible  with  its  observations.  Let  us  take  the  part  of  A  first.  In  our  abbreviated 
notation,  the  only  event  she  observes  is  (. KAS  k  :  S  — >  A).  Under  the  assumptions  that  KAS 
is  uncompromised  for  A  and  S  and  the  honesty  of  S  (derived  from  his  role),  A  can  completely 
reconstruct  the  expected  run.  In  symbols: 

A:  uncompromised(iL"4,s,  [A,  5])  A  honest  S  A 

(Kas  k:S^  A)  a 

=►( vk)s  <  (KAS  k:  S  ->  A)s<  <  (Kas  k  :  S  A)a 

This  formula  means  that,  under  the  stated  hypotheses,  all  runs  that  arc  compatible  with  ,4’s  observa¬ 
tion  must  include  the  shown  actions  of  S,  and  in  the  prescribed  order. 

The  uncompromised  hypothesis  identifies  S  as  the  originator  of  the  transmitted  message  (A  is  ex¬ 
cluded  thanks  to  the  notme  axiom)  while  the  honesty  assumption  completes  the  sequence  of  messages 
that  preceded  this  send.  A  more  formal  derivation  is  given  by: 

Qa  :  ( KSA  k  :  S  A)a 
(rev)  :  (( Ksa  k))x<  <  ( KSA  k:S^A)A 
uncompromised(/Tj4's',  [A,  5])  :  X  =  A  or  X  =  S 

(notme)  :  X  f  A 

honest  S  :  (uk)s  A  ( KSA(k )  :  S  — *  A)s 

(uk)s  <  ( KSA  k:S  -  A)s<  <  ( Ksa  k)A 

On  the  other  hand,  S  does  not  conclude  more  than  he  observes  since  he  is  the  recipient  of  no 
message. 

In  this  example,  A  is  a  parameter  in  S’ s  role  and  S  is  a  parameter  in  ,4’s.  In  a  real  system,  this 
would  mean  that  these  values  appeal-  in  some  configuration  file  on  the  client  and  server’s  machines. 
While  the  former  may  be  acceptable  if  there  is  only  one  server  in  the  system,  the  latter  is  certainly  not 
as  a  server  should  be  able  to  distribute  keys  to  more  than  one  client. 

We  introduce  the  discharging  transformation  DC  to  transform  a  role  that  gets  a  value  from  a 
parameter  into  a  role  that  acquires  this  value  as  part  of  the  protocol  run.  This  transformation  simply 
turns  a  parameter  into  a  binder.4  For  simplicity,  take  a  sequential  role  [x}p:  p'(x')  with  parameter  x, 
an  action  prefix  p  that  does  not  refer  to  x,  and  remaining  actions  p'(x)  that  may  reference  x.  Then, 
DC  is  defined  as  follows  on  this  role: 

BC[[x\p-,p(x)]  =  p-1ax-1p(x ) 

4There  are  other  ways  to  discharge  a  parameter  x:  for  example  another  useful  transformation  removes  a  match  (xo/x) 
against  x  and  replaces  other  occurrences  with  xo .  This  would  be  how  to  discharge  S  in  KD? .client  above. 
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where  ax  is  some  action  that  binds  x  (most  interesting  is  a  receive).  The  generalization  to  non¬ 
sequential  roles  is  trivial,  but  harder  to  typeset. 

For  example,  an  instance  of  DC  discharges  A  in  KD^  server  above  by  having  A  send  her  name  to 
S'  in  a  request  message: 


A  S 


The  roles  give  a  more  precise  account  of  the  operations  of  DC: 

KD}_server[S]  =  (A  :  A  -»•  S)  ;  v  k  ;  (KAS  k  :  S  -»•  A) 

KD}_client[A;  S]  =  (,1  :  ,1  —  S)  (. KAS  k  :  S  ->  A) 

Observe  that  KD*_server  does  not  have  ,4  as  a  parameter.  S  obtains  ,4’s  name  from  the  first  message, 
either  from  the  body  or  from  its  putative  sender  at  the  implementor’s  choice.  A  simple  prefixing 
transformation  is  used  to  have  the  client  send  this  message,  upgrading  KDj.client  to  KD^.client. 
Note  that  it  does  not  discharge  S  as  a  parameter. 

A  transformation  operates  not  only  on  the  syntactic  specification  of  a  role,  but  also  on  its  inferable 
properties.  In  its  generality,  the  transformation  DC  is  rather  limited  in  this  respect:  it  extends  the 
observations  of  principal  executing  the  affected  role  with  the  action  ax  —  here  {A  :  A  — >  S)  —  and 
only  influences  the  deductions  of  other  principals  through  its  altered  honesty  assumption.  From  the 
point  of  view  of  the  principal  executing  the  transformed  role,  DC  operates  as  follow  on  the  sequential 
illustration  above,  where  we  make  an  intuitive  use  of  the  symbols. 

A:  <  <Fp/  A  ’T  -*■  <&'p  <  4>'p,  A  4'' 

DC 

*\r 

A:  <f>p  <  ax  <  4y  A  — >  <&'p  <  ax  <  &p,  A  4T 

We  will  see  transformations  that  have  more  interesting  effects  shortly.  Note  however  that  the  presence 
of  event  ax  may  enable  further  inferences. 

This  makes  S’ s  point  of  view  marginally  more  interesting  than  in  the  first  version  of  this  protocol: 
upon  receiving  the  first  message,  he  can  use  axiom  rev  to  infer  that  someone  sent  it,  although  not 
necessarily  A: 

S :  (A:A^S)s  <  {vk)s  <  (KAS  k)s 

(A:A->S)X<  <  (A:A->S)s  <  (uk)s  <  (KAS  k)s 

We  next  examine  the  property  deducible  by  A:  it  illustrates  the  effect  of  DC  on  the  other  party, 
and  describe  the  effect  of  the  prefixing  transformation.  Her  view  is  summarized  by  the  following 
formula: 

A:  uncompromised(/W4s',  [A,  5])  A  honest  S' A 

(A:A^S)a  <  ( KASk)A 

{A  .  A  — >■  S) a  ,  /  ka&  k)  a 

(A:A^S)s  <  {yk)s  <  (KASk)s<\  <  (  M 

The  two  occurrences  of  (A  :  A  — r  S)A  arc  the  result  of  the  prefixing  transformation  on  the  client’s 
role.  The  matching  receive  action  {A  :  A  — >  S)s  is  deduced  from  the  honesty  of  S.  Observe  that  A 
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is  unable  to  correlate  her  sending  of  this  message  with  S’ s  reception.  Indeed,  S  will  perform  its  role 
not  in  response  to  ,4’s  request  but  following  the  reception  of  any  message  of  the  form  (A  :  A  — ►  S), 
whoever  the  actual  sender  is.  Of  course,  A  will  not  accept  an  unsolicited  key,  but  if  she  sent  a  request 
there  is  no  guarantee  that  S’ s  response  has  any  relation  to  it.  While  this  property  does  not  exactly 
match  the  expected  run  of  this  updated  protocol,  it  may  be  acceptable  since  A  still  gets  what  she 
asked  for  (even  if  she  was  not  heard).  We  will  examine  valiants  of  this  protocol  that  enforce  stronger 
guarantees  between  request  and  response. 


3.2  Two-Party  Key  Distribution 


With  this  exercise  under  our  belt,  we  will  now  examine  protocols  in  which  a  server  S  generates  a  key 
k  and  distributes  it  to  two  parties  A  and  B.  This  is  the  setting  underlying  NSSK  and  Kerberos,  which 
we  will  study  in  sections  to  come.  Note  that  our  analysis  generalizes  to  an  arbitrary  number  of  parties. 

We  start  with  the  2-party  valiant  of  the  basic  scheme  presented  in  Section  3.1.  The  expected  run 
is  as  follows: 

A  S  B 

o 

I<ASk  KBSk 

O  -  o  - >■  o 

While  we  take  it  as  primitive  for  simplicity,  it  is  easy  to  define  a  transformation  that  produces  an 
n-party  valiant  of  that  basic  protocol  in  Section  3.1  for  any  given  number  n. 

The  roles  of  this  protocol  are  defined  next.  Notice  that  the  actions  of  A  and  B  arc  totally  sym¬ 
metric  at  this  stage  (only  A’s  role  is  shown). 

KD°_server [S;  A;B]  =  is  k  ;  (KAS  k  :  S  A)  <g>  (KBS  k  :  S  ->  B) 

KD°  client[^4;  5,  B]  =  ( I<AS  k  :  S  -*  A) 


Next  we  take  the  point  of  view  of  a  client  {A  for  example)  and  follow  our  footprints  from  Section  3.1 
to  derive  the  property  characterizing  her  observations: 


A  : 


uncompromised(iij4's',  [A,  5])  A  honest  S' A 

(. Kas 


k)A 


=>  (is  k)s  < 


'{ KAS  k  :  S  A)s< 
(Kbs  k  :  S  B)s< 


<  (KAsk)A 


Next  we  use  the  discharging  transformation  DC  to  have  A  pass  the  names  of  the  two  clients  to  S, 
discharging  A  and  B  as  parameters  in  KDS^server.  The  resulting  run  is  given  by: 


A 

o 


A,B 


Kas  k 


S 

>  o 
| uk 
—  O  — 


B 


Kbs  k 


and  the  roles  by: 

KDi_server[S] 

KDj-iclientf^l;  S,  B] 
KD^-rclientff?;  S,  A] 


(. A ,  B  :  A  — >  S)  ;  is  k  ; 

(KAS  k:S  ->  A)  ®  ( I<BS  k:  S B) 

(A,  B  :  A —>■  S)  ]  (I<AS  k  :  S  —>  A) 

(. I<BS  k:S  -+B) 
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Observe  that  the  roles  of  A  and  B  arc  not  symmetric  any  more.  Note  also  that  it  would  make  little 
difference  if  A  transmitted  just  “B”  as  her  first  message  since  her  name  is  present  in  the  “from”  field 
of  this  action. 

The  properties  characterizing  ,4’s  and  B's  views  are  derived  as  in  the  previous  section.  Let  us 
examine  them: 


A  :  uncompromised(ivA‘s',  [A,  5])  A  honest  S' A 

(A,B)a 


|  (A,  B) A 

(■ A,X)S  <  ( vk)s  < 

'  (Kas  k:  S  - 
(Kxs  k:  S  - 

A)s< 
A  X)s< 

<  ( KAsk)A 

<  ( KAsk)A 


B  :  uncompromised(/vB5,  [B,  5])  A  honest  S  A 

=*  (X,B:X^S)s  <  {v  k)s  <  {^bs 


<  ( KBSk)B 

<  (. KBSk)B 


Observe  that  A  has  no  way  to  determine  whether  S  transmitted  the  key  k  to  B  or  to  some  other  party 
X.  Indeed,  she  can  only  infer  that  S  received  a  request  for  a  key  involving  herself  and  some  X, 
not  necessarily  B.  By  a  similar  argument,  B  cannot  ascertain  to  whom  k  was  distributed,  even  if  A 
appeal's  among  the  parameters  of  his  role. 


This  problem  is  traditionally  solved  by  having  S  include  /i’s  name  into  the  message  directed  to 
A,  and  ,4’s  name  into  B's  message.  In  our  setting,  this  is  achieved  by  a  transformation  CA  that  inserts 
a  new  term  into  an  existing  encryption: 


CAm/  [km]  =  k  (■ m ,  m!) 


This  has  the  effect  of  cryptographically  authenticating  m!  (hence  the  name  CA)  to  any  party  entitled 
to  access  the  ciphertext.  It  operates  as  follows  on  a  property  derivable  to  a  party  receiving  this  message 
(we  omit  additional  formulas  that  may  occur  in  the  antecedant  or  consequent): 


A  : 


uncompromised(&:,  [A,  B])  A  ((k  rn))A 
{{k  m))B<  <  {{k  m))A 


jCAm/ 

A  :  uncompromised(A:,  [ A ,  B])  A  ((k  (m,  m')))A 
=>  {{k  ( m ,  m’)))B<  <  ((k  (m,  m’)))A 

The  transformation  simply  extends  to  the  added  component  m!  the  fact  that  a  message  encrypted  with 
an  uncompromised  key  is  authenticated.  Note  that  B's  honesty  is  not  required  as  long  as  k  is  not 
compromised. 

By  applying  this  transformation  twice  (once  for  A  and  once  for  B),  S  can  inform  A  and  B  of 
whom  it  created  k  for.  This  also  allows  us  to  discharge  A  as  a  parameter  in  B's  role.  The  expected 
run  is  now  given  by  the  following  diagram: 


A  S  B 

A,B 

o - s-  o 

Kas  ( B,k )  \vk  Kbs  ( A,k ) 

O  -6 -  O  - s-  O 
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while  the  roles  become: 

KDj-serverfS]  =  (A,  B  :  A  — >  S)  ;  u  k  ; 

( Kas  (B,  k)  :  S  —>  A)  ®  { Kbs  ( A ,  k)  :  S^B) 

KD^iclient[A;  S,B]  =  (A,B:A^S);  ( KAS  (B,  k)  :  S  ->  A) 

KD|_rdient[5;  S }  =  ( I\BS  {A,  k)  :  5  -»•  5) 

It  is  easy  to  see  that  the  application  of  CA  solves  the  problem  outlined  earlier.  Indeed,  A  and  B  can 
derive  the  following  properties: 


A  : 


uncompromised(/xj4's,  [A,  S'])  A  honest  S  A 


(A  B)  A 

{- A,B)a 


( A,B)s  <  {vk)s  < 


(Kas 
(Kbs 


( B,k))s< 
(A,  k))s< 


<  (Kas  (B,  k))A 

<  (Kas  (B,  k))A 


B  :  uncompromised(Jt  ^ BS,  [B,  5])  A  honest  S  A 


=>-  (A,B)S  <  (vk)s  < 


(KAS  ( B,k))s< 
(Kbs  ( A,k))s< 


(- KBS  ( A,k))B 
(Kbs  (A,  k))B 


While  these  formulas  are  very  similar  to  what  we  derived  for  protocol  KD A  and  B  now  know  that 
the  key  k  is  intended  for  the  two  of  them  to  communicate,  not  a  third  party  (assuming,  of  course  that 
S  is  honest  and  that  the  keys  KAS  and  KBS  are  not  compromised).  Clearly,  this  correction  becomes 
crucially  important  when  A  and  B  attempt  to  use  k. 


While  KDj  achieves  a  minimal  form  of  key  distribution  (we  will  soon  extend  this  basic  function¬ 
ality  with  additional  guarantees),  few  actual  protocols  have  this  message  structure.  Indeed,  with  the 
exception  of  recent  group  protocols  [11],  nearly  all  key  distribution  protocols  based  on  shared  keys 
have  the  server  send  both  components  KAS  (B,  k)  and  KBS  (A,  k)  to  one  principal,  who  then  relays 
the  part  he  does  not  understand  to  the  other. 

Appendix  A  describes  the  relay  transformation  MT  that  has  the  ability  to  turn  KD|  into  a  more 
common  form  of  key  distribution.  The  resulting  run  is  as  follows: 


A  S  B 

A,B 

o - s-  o 

Kas  ( B,k ),  KBS  ( A,k )  \vk 
O  -  o 

\  Kbs  ( A,k ) 

o - o 

In  this  protocol,  which  we  will  call  KDj,  S  concatenates  KAS  ( B,k )  and  KBS  ( A,k ),  and  sends 
the  resulting  message  to  A,  who  then  forwards  KBS  (A,  k)  to  B.  Several  academic  and  industrial 
protocols,  e.g.,  Kerberos  5,  follow  this  pattern.  The  role  specification  is  as  follows: 

KD^serverfS]  =  (A,B  :  A  -»•  S)  ;  v  k  j 

(I<AS  ( B,k ) ,  IxBS  (A,  k)  :  S  —>  A) 

KD|_iclient[A;  S,  B]  =  (A,  B  :  A  ->  S)  ;  (K As  ( B ,  k),M  :  S  -*  A)  ; 

(M  :  A  — ►  B) 

KD3_rclient[S;  S }  =  ( KBS  (A,  k)  :  A  -»■  B) 
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Clearly,  the  component  KBS  (A,  k )  is  opaque  to  A.  Hence  her  role  mentions  a  generic  message  M. 

Transformation  MT  alters  the  properties  derivable  to  A  and  B  in  a  rather  subtle  way.  We  examine 
its  effect  one  principal  at  a  time. 

A:  uncompromised(/xA5,  [A,  5])  A  honest  S' A 

(A,B)a  <  (Kas  M)a  <  (M)a 

( A,B)a 

( A,B)s  <  (uk)s  <  (KAS(B,k), 

<  (KAS  (B,k),m)[x<\  <  (KAS  (B,k),m)A  <  ( M)a 

Compared  to  the  analogous  property  of  KD^,  ,4’s  receive  action  contains  a  generic  M,  and  the  server 
sends  a  concatenated  message  rather  than  the  two  components  separately.  This  has  two  major  impli¬ 
cations.  We  highlighted  them  using  boxes: 

1.  While,  by  the  honesty  assumption,  A  knows  that  S  has  sent  KAS  (B,  k),KBS  (A,  k ),  she  has 
no  means  to  ascertain  that  the  generic  message  M  she  receives  is  indeed  KBS  (A,  k). 

2.  Since  KAS  is  uncompromised,  A  knows  that  S  has  originated  KAS  (B.  k ),  but  she  cannot  be 
sure  of  who  originated  the  message  KAS  (B.  k),  M  she  received:  hence  the  variable  X  for  its 
originator,  and  the  <  relation,  a  direct  result  of  applying  axiom  rev.  Indeed  an  attacker  could 
have  replaced  KBS  (A,  k)  with  an  arbitrary  message  in  an  undetectable  way.  Such  a  behavior 
has  been  documented  for  Kerberos  5  [2], 

Additionally,  observe  that  A’s  last  send  has  little  bearing  on  the  overall  property  and  could  be  dropped 
without  significant  consequences  (it  is  the  same  underlying  reason  that  makes  the  property  derivable 
by  the  server  so  uninteresting). 

For  similar  reasons,  B  has  no  way  to  know  who  forwarded  the  message  he  receives. 

B  :  uncompromised(A'B‘s,  [H,  5])  A  honest  S  A 

(I\BS  ( A,k))B 

=>  ( A,B)s  <  {uk)s  <  (KAS  (B,k),  KBS  (A,k))s<  < 

<  (Kbs  (A,k))x<  <  (KBS  (A,k))B 

Note  that  if  B  were  able  to  infer  that  X  is  indeed  A ,  he  would  also  reach  the  certainty  that  A  knows 
the  key  k. 

We  conclude  this  section  by  deriving  a  popular  variant  of  KD^,  in  which  B' s  component  is  em¬ 
bedded  in  A’s  rather  than  concatenated  with  it.  Actual  protocol  that  follow  this  approach  include 
NSSK,  Denning-Sacco  and  Kerberos  4. 

The  transformation  EA  that  produces  this  modified  protocol  is  similar  to  CA: 

EA  [{km),m!]  =  k(m,m ) 

It  pushes  an  existing  message  into  an  encrypted  component  it  is  concatenated  with.  The  effect  of  EA 
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over  properties  is  to  authenticate  m'  in  addition  to  m: 


A  :  uncom promised (/c,  [A.  B ])  A  (( k  m,  m'))A 
=>■  (( k  m  ))b<  <  ((km,  m'))x<  <  ((km,  m'])A 

EA 

"A 

A  :  uncompromised(/c,  [A,  B ])  A  ((k  (m,  m')])A 
=>  ((k  (m,  m')))B<  <  ((k  (m,  m')))A 

Notice  the  relation  ((km)) b<  <  ((km,  m!))x<  before  applying  the  transformation:  it  says  that  B  has 
originated  a  message  containing  k  m,  which  may  or  may  not  be  k  m,  rn! ,  and  that  what  B  received 
may  have  been  put  together  by  a  principal  X.  Recall  that  we  ran  into  this  issue  several  times  while 
examining  KD|.  This  transformation  removes  this  source  of  uncertainty. 

Applying  EA  to  KD2  yields  protocol  KD^,  which  has  the  following  expected  run: 


Kas  ( B,k,KBS  ( A,k ))  \vk 


\  Kbs  ( A,k ) 


KD2  is  more  formally  defined  by  the  following  roles: 

KD^serverfS]  =  (A,  B  :  A  — >  S)  ;  v  k  ; 

(Kas  (B,k,KBS  (A,k))  :  S  -»•  A) 

KD2  Jclient[A;  S,  B]  =  (A,B:A->S);  (KAS  (B,  k,  M )  :  S  -»•  A)  ; 

(M  :  A  — >  B) 

KD^rclient [B\  S\  =  (KBS  (A,  k)  :  A  -*  B) 

.4’s  resulting  property  enhances  what  she  could  deduce  from  KD)  with  the  certainty  that  the  opaque 
submessage  M  she  receives  is  precisely  KBS  (A,  k ): 

A:  uncompromised(iTj4,s,  [A,  5])  A  honest  S  A 

(A,B)a  <  (Kas  (B,  k,  M))a  <  (M)a 

^  '  ( A,B)a 

(A,B)S  <  (uk)s  <  (KAS  (B,k,KBS  (A,k)))s< 

<  (Kas  (B,k,\K^s  (A,k) \)A  =  (KAS  (B,k,\m)A  <  (M)a 


At  first  sight,  B' s  view  does  not  significantly  differ  from  what  he  could  infer  in  KD|: 

B  :  uncompromised(A''B5,  [B,  5])  A  honest  S  A 

(Kbs  (A,  k))B 

=>  (A,B)s  <  (uk)s  <  (KAS  (B,k,KBS  (A,k)))s<  < 
<  (Kbs  (A,  k))x<  <  (KBS  (A,  k))B 
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Indeed,  assuming  S  honest  and  KBS  uncompromised,  he  can  deduce  that  S  did  its  paid  in  the  protocol, 
and  that  some  principal  X  (not  necessarily  A)  forwarded  I\  BS  ( A ,  k)  to  him. 

However,  under  the  additional  assumption  that  KAS  is  not  compromised  either,  B  can  infer  that 
it  is  A  who  forwarded  this  message  to  him.  In  particular,  this  tells  B  that  A  knows  k. 

B:  uncompromised(if'B,s',  [B,  5])  A  honest  S  A 

uncompromised(/iAS',  [A,  S'])  A  (KBS  (A,k))s 
=>  (A,B)s  <  ( vk)s  <  {KAS  (B,  k,  Kbs  (A,  k)))s<  < 

<  (I\BS  [A,  k))A<  <  (Kbs  (A,k)  :  X  ^  B)b 

Note  that  the  assumption  of  uncompromised(/v AS ,  [A,  5])  would  be  irrelevant  in  any  of  B' s  previous 
inferences:  only  A  could  decrypt  KAS  ( B ,  k.  KBS  ( A ,  k ))  to  forward  KBS  (A,  k),  hence  accessing 
k.  Note  also  that  the  assumption  that  KAS  is  uncompromised  does  not  mean  that  A  is  bound  to  be 
honest:  she  could  indeed  deviate  substantially  from  the  protocol,  passing  information  (but  not  KAS ) 
to  arbitrary  parties,  but  she  certainly  has  decrypted  S’ s  message  and  certainly  sent  out  KBS  (A,  k) 
(although  not  necessarily  to  B). 

While  most  academic  and  industrial  key  distribution  protocols  based  on  shared  keys  arc  derived 
from  either  KDj  or  KDj,  these  fragments  lack  two  important  guarantees:  recency  and  key  confirma¬ 
tion.  Indeed,  both  KDj  and  KDj  give  the  clients  A  and  B  assurance  that  the  key  k  has  been  generated 
by  the  server  for  their  exclusive  communication  needs,  but  they  provide  no  verifiable  guarantee  that  k 
was  generated  recently:  an  old  k  is  more  likely  to  have  been  compromised  than  one  produced  within 
a  short  time  frame.  None  of  the  properties  in  this  section  binds  the  generation  of  k  by  any  event 
controlled  by  the  client  receiving  it.  Key  confirmation  is  about  a  client  having  some  reason  to  believe 
that  his  counterpart  has  knowledge  of  k  as  well:  only  KD^’s  B  is  able  to  gather  this  type  of  evidence 
(under  assumptions).  In  the  next  sections,  we  will  follow  the  development  of  two  known  families  of 
protocols  and  observe  how  they  address  these  issues. 

4  Derivations  of  NSSK 

This  section  extends  the  results  we  just  obtained  in  the  direction  of  the  Neeclh am -S ch roede r  shared- 
key  protocol  (NSSK)  [13].  In  Section  4.1,  we  describe  how  a  challenge-response  exchange  is  used  to 
guarantee  the  recency  of  the  key,  but  also  point  out  how  a  partial  application  of  this  technique  leads 
to  Denning  and  Sacco’s  classical  attack  on  NSSK  [5],  We  then  show  how  Needham  and  Schroeder’s 
subsequent  fix  to  the  original  NSSK  [14]  essentially  completes  the  application  of  nonce-based  recency 
in  Section  4.2.  Finally,  we  address  key  confirmation  as  implemented  in  most  protocols  in  Section  4.3. 

4.1  Guaranteeing  Recency  with  Nonces 

As  mentioned  earlier,  the  core  key  distribution  protocols  derived  in  Section  3  do  not  guarantee  to  the 
clients  that  the  server  has  generated  the  key  recently.  Indeed,  none  of  the  formulas  we  have  derived 
for  any  of  our  clients  bounds  the  actions  of  an  honest  server  so  that  it  follows  that  the  key  could  not 
have  been  produced  at  an  arbitrary  moment  in  the  past.  Note  that  this  is  not  a  failure  of  honesty:  the 
server  may  have  received  a  fake  request  long  before  our  clients  felt  any  need  to  communicate;  the 
response  could  have  been  cached  by  a  dishonest  agent,  who  also  intercepted  the  clients’  request  and 
replayed  that  response  in  a  timely  manner. 
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A  controllable  way  for  a  client  to  ensure  that  the  key  is  recent  is  to  bracket  its  generation  between 
two  of  its  own  events.  One  approach  to  doing  so  is  using  the  challenge-response  mechanism:  the 
client  issues  a  fresh  challenge  at  the  time  she  sends  the  key  distribution  request  to  the  server.  The 
server  cryptographically  binds  the  response  to  the  challenge  and  the  response  to  the  key  distribution 
request.  We  dedicate  this  section  to  examining  one  of  the  possible  concrete  realizations  of  this  idea, 
adopted  in  NSSK  and  other  protocols.  A  different  approach,  using  time-stamps,  will  be  examined  in 
Section  5  when  analyzing  the  Kerberos  family. 

We  use  a  specific  instance  of  the  cr  axiom  from  Section  2.5  which  sends  the  challenge  in  the  clear 
(the  challenge  function  is  the  identity)  and  returns  the  response  encrypted  with  an  uncompromised 
shared  key:  we  have  used  it  as  an  example  in  Section  2.5.  As  a  refresher,  the  run  of  this  protocol  is  as 
follows,  where  we  write  the  parameters  as  we  will  use  them: 


A 

o 

v  n  j 
o 


n 


Kas  n 

o  -< - 


s 


^  o 
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The  specific  guarantees  of  this  protocol  arc  the  following: 

A  :  uncompromised(Jvj4's,  [A,  5])  A 

{vn)A  <  {u)a  <  ( KAsn)A 

=*>  (vn)A  <  (n)A  <  (( n))s  <  (( KAsn))s<  <  {KAS  n)A 

The  transformation  allowing  to  embed  a  challenge -response  exchange  in  another  protocol  has 
been  extensively  discussed  in  [11].  We  present  it  only  informally  here,  using  protocol  KD\  as  our 
case  study  since  it  is  at  the  core  of  NSSK.  The  following  diagram  intuitively  renders  the  overall  effect 
of  this  transformation: 
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Intuitively,  the  transformation  MC  has  the  effect  of  merging  two  independent  protocols  by  identifying 
some  sends  and  receives  between  the  same  principals  and  fusing  them  through  concatenation.  Events 
that  do  not  involve  communication  arc  compounded.  Here,  the  challenge  message  (n  :  A  —>  S)  is 
concatenated  with  A’s  request  to  S  ( A ,  B  :  A  —>  S)  into  the  message  (n,  A,  B  :  A  — r  S ).  The  two 
responses  are  processed  similarly.  The  properties  induced  by  this  transformation  arc  little  more  than 
what  holds  of  the  two  protocols  separately.  Transformation  MA  consolidates  the  two  encryptions 
with  Kas  into  one.  It  has  a  similar  binding  power  to  EA  from  section  3.2. 

The  resulting  protocol  includes  the  first  three  steps  of  NSSK  (the  addition  of  key-confirmation 
will  complete  it  in  Section  4.3).  We  formalize  by  presenting  its  roles. 

NSSKo-server[S']  =  (n,  A,  B  :  A  — ►  S)  ;  v  k  ; 

(Kas  (n,  B,  k,  Kbs  ( A ,  k)):  S  — ►  A) 

NSSKo-iclientfA;  S,  B]  =  v  n  ;  (n,  A,  B  :  A  — r  S)  ; 

(KAS  (n,  B,  k,  M)  :  S  — >  A)  ;  (M  :  A  — >  B) 

NSSK0_rclient[.B;  S }  =  (KBS  (A,  k)  :  A ->  B) 

B' s  role  does  not  change  at  all  from  KDj.  the  server’s  changes  only  marginally,  while  most  changes 
occur  in  A’s  role. 

It  is  particularly  interesting  to  compare  how  the  properties  derivable  to  A  and  B  change  from 
what  we  obtained  for  KD^.  Because  A  created  the  nonce  n  fresh  and  it  is  returned  cryptographically 
authenticated  together  with  the  key  k,  A  can  be  certain  that  the  server  has  generated  k  after  her  request. 
The  analogous  property  for  KDj  left  the  relation  between  the  (actual)  request  and  the  generation  of 
the  key  totally  open.  Thus,  NSSK  ensures  the  recency  of  the  key  to  A. 

A:  uncompromised(iTA,s',  [A,  S'])  A  honest  S  A 

(vn)A  <  (n,  A,  B) A  <  (KAS  (n,B,k,M))A 

=>  ( vn)A  <  (n,  A,  B)a  <  ( n,A,B)s  <  (v  k) s  < 

<  (I<AS  (n,  B,  k,  Kbs  ( A ,  k)))s<  <  {KAS  (n,  B,  k,  KBS  {A,  k))A 

We  have  dropped  the  last  message  (( M)A )  since  it  does  not  influence  the  resulting  property. 

The  guarantees  derivable  to  B  are  however  pretty  much  the  same  as  in  KDj:  B  gets  to  deduce  that 
some  nonce  n  has  been  exchanged  from  S' s  honesty.  However,  no  event  controlled  by  B  necessarily 
precedes  the  generation  of  k.  We  use  the  stronger  version,  in  which  KAS  is  assumed  uncompromised. 

B  :  uncompromised(/wB,s',  [B,  5])  A  honest  S  A 

uncompromised(iTA5,  [A,  5])  A  (KBS  (A,  k))s 
=>  ( n,A,B)s  <  (vk)s  <  (KAS  (n,  B,  k,KBS  {A,  k)))s<  < 

<  (Kbs  (A,  k))A<  <  (KBS  (A,k)  :  X  -  B)b 

Therefore,  NSSK  does  not  ensures  the  recency  of  the  key  to  B.  This  is  the  gist  of  Denning  and 
Sacco’s  attack  on  NSSK  [5]. 

4.2  NSSK-fix 

A  few  years  after  Denning  and  Sacco  pointed  out  the  absence  of  recency  guarantees  for  the  respon¬ 
der  [5],  Needham  and  Schroeder  came  forth  with  a  “fix”  for  their  original  protocol  [14].  This  ad¬ 
justment  simply  inserts  an  additional  challenge  response,  between  B  and  the  server,  to  provide  the 
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required  assurance.  Minor  complications  are  called  for  in  order  to  maintain  A  as  the  initiator  and 
avoid  message  confusion.  We  will  now  examine  this  amended  protocol. 

B’s  challenge  response  differs  from  .4’s  in  order  to  avoid  confusion.  B  generates  a  nonce  nB 
(for  symmetry  we  rename  /l’s  nonce  np,  sends  it  encrypted  to  the  responder  and  expects  it  back  also 
encrypted,  but  somehow  transformed.  The  expected  run  is  as  follows: 


S  B 

o 

KBS{f{nB))  \VUB 

o  ^ - o 

I  Kbb  ( g(nB )) 

o - >-  o 


with  /  and  g  two  different  message  structures  parameterized  by  nB.  The  properties  of  this  exchange, 
from  the  point  of  view  of  B  are  typical  of  a  challenge-response  with  shared  keys: 

B  :  uncompromised(/TB,s,  [. B ,  S ])  A 

{ynB)B  <  (I<BS  (f(nB)))B  <  {KBS  (g(nB)))B 

=>-  ( vnB)B  <  (KBS  (f(nB)))B  < 

<  (( KBS  (f(nB))))s  <  « KBS(g(nB))))s<  <  (KBS  (g(nB)))B 

The  proof  is  similar  to  what  we  saw  in  Section  2.5. 

The  specific  instance  used  in  NSSK-fix  takes  f{nB)  =  ( A,nB )  and  g{nB)  =  (nB),  although  any 
functions  would  do,  as  long  as  they  are  not  identical  and  they  truly  depend  on  nB.  NSSK-fix  itself  is 
obtained  by  applying  a  series  of  transformations  to  NSSK  and  this  challenge-response  exchange: 

•  Two  applications  of  the  routing  transformation  MT  modify  the  challenge-response  so  that  B 
and  S  communicate  through  A. 

•  Similarly  to  Section  4.1,  transformations  MC  and  MA  merge  this  modified  challenge-response 
and  NSSKo,  and  cryptographically  bind  B’s  nonce  within  the  the  key  distribution  submessage 
S  intends  for  B. 

•  Finally,  transformation  DC  discharges  A  from  B’s  roles,  allowing  that  principal  to  remain  the 
initiator  of  the  final  protocol. 
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The  overall  transformation  is  summarized  in  the  following  diagram: 
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Observe  that  the  resulting  protocol  is  substantially  more  complex  than  NSSKo  (in  the  upper  left 
corner):  it  contains  two  additional  steps  and  one  more  cryptographic  operation.  Note  that  it  may  be 
rather  complicated  to  extend  this  protocol  to  an  //-party  key  distribution. 

This  protocol  differs  from  NSSK-fix  only  by  the  absence  of  the  final  key-confirmation  steps.  They 
will  be  added  in  Section  4.3.  Its  roles  are  given  next. 

NSSKfixo_server[S']  =  (ha,  A,  B,  KBS (A,ub)  ■  A  — >  S)  ;  u  k  ; 

(KAS  (nA,B,k,KBS  (A,k,nB))  :  S  ^  A) 

NSSKfix0 _iclient[A;  S,B]  =  {A  :  A  -»•  B)  ;  (M'  :  B  —>  A)  ; 

v  nA  ;  (riA,  A,  B ,  M’  :  A  — r  S)  ; 

(. KAS  (■ nA ,  B,  k,  M):  S  ->  A)  ;  (M  :  A  ^  B) 

NSSKfixo_rclient[f?;  5]  =  (A  :  A  —>  B)  ■,  v  nB  {KBS (A,nB)  :  B  —>  A)  ; 

(KBS  {A,k,nB)  ■■  A->  B) 

We  now  turn  to  the  properties  that  each  principal  can  derive.  .4’s  deduction  differ  from  NSSKq 
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only  by  the  presence  of  her  two  extra  actions,  and  by  the  fact  that  an  honest  server  will  correctly  inter¬ 
pret  the  added  fields,  both  in  her  request  and  in  its  response.  In  particular,  A  is  perfectly  aware  that  the 
component  she  forwards  to  B  in  her  last  message  (omitted  below)  has  the  structure  KBS  ( A,k,nB ) 
for  some  value  nB-  The  logical  statement  is  as  follows: 

A:  uncompromised(/ij4's,  [A,  5])  A  honest  S  A 

{A) A  <  (. M')a  <  (y  ua)a  <  { nA,A,B,M')A  < 

<  (Kas  (nA,  B,  k,  M))a 

=*>  (A) a  <  ( M')a  <  {u  nA)A  <  (nA,A,B,M')A  < 

<  (nA,  A,  B,  Kbs(A,  nB))s  <  (vk)s  < 

<  (Kas  (nA,  B,  k,  Kbs  (A,  k,  nB)))s<  < 

<  (KAS  (nA,B,k,KBS  (A,k,nB))A 

Since  A  now  supposedly  receives  a  message  from  B,  it  makes  sense  to  ask  what  would  be  the  effect 
of  strengthening  the  assumptions  of  this  property  with  uncompromised(it B  ,  [B,  .S’] ).  This  brings 
no  advantage  since  A  simply  forwards  B's  first  message  and  has  no  way  to  inspect  or  verify  its 
contents,  even  indirectly.  The  additional  assumption  that  B  is  honest  brings  some  marginal  additional 
insight,  namely,  that  B  performed  its  initial  three  actions  (with  the  right  parameters)  before  S  started 
processing,  but  she  has  no  way  of  ordering  these  added  events  with  respect  to  her  own  initial  actions. 

The  interesting  changes  occur  from  B’s  perspective.  As  in  A’s  case  in  NSSKo,  B's  nonce  is 
cryptographically  bound  to  the  key  k  he  receives  by  protocol’s  end.  Since  an  honest  server  will 
construct  this  key  only  after  retrieving  this  nonce  from  B's  encrypted  message,  the  generation  of  the 
key  is  sandwiched  between  two  events  under  B's  control,  hence  ensuring  its  recency.  The  rest  of 
this  property  allows  him  to  draw  similar  conclusions  as  in  NSSKo,  namely  that  S  produced  the  key, 
forwarded  it  to  A  who  learned  it  and  forwarded  it  to  B.  This  is  summarized  in  the  following  property. 

B:  uncompromised(A'B5,  [B,  5])  A  honest  S  A 

uncompromised(/ij4,s',  [A,  5])  A 

(A)b  <  {vnB)B  <  (BBS  (A,ub))b  <  {KBS  (A,k,nB))B 
=>  ( A)b  <  (y  ub)b  <  {KBS  {A,ub))b  < 

<  (nA,  A,  B,  Kbs  (A,  nB))s  <  (vfys  < 

<  (Kas  (nA,B,k,KBS  (A,k,nB)))s<  < 

<  {Kbs  (A,k,nB))A<  <  ( KBS  ( A,k,nB))B 

As  in  NSSKo,  dropping  the  assumption  that  KAS  is  uncompromised  simply  implies  that  B  does  not 
know  who  has  originated  the  message  KBS  (A,  k,nB)  and  that  he  cannot  be  certain  that  A  knows  k. 

4.3  Key  Confirmation 

The  previous  two  sections  have  shown  how  to  extend  the  core  key  distribution  protocol  KDj  in  with 
the  recency  guarantees  of  NSSK(-fix).  The  remaining  issue  to  address  is  ensuring  to  both  recipients 
that  their  counterpart  also  knows  the  new  shared  key.  As  we  observed,  under  assumptions,  these 
protocols  already  guarantee  this  to  B,  but  A  has  no  means  to  be  sure  that  B  ever  learned  k. 

In  order  to  make  this  concept  more  explicit,  we  define  the  predicate  has(,4,  rri)  that  holds  only  if 
principal  A  has  seen  term  m.  Intuitively,  this  is  the  case  whenever  we  know  that  A  has  performed  an 
action  on  m.  Here  is  a  partial  definition,  incomplete  but  sufficient  for  our  needs.  It  could  clearly  be 
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extended  with  additional  cases. 


has(A,  m)  = 


(. x/K  (m,  m'))A 
{{ K  (m,  m')))A< 
(. x/mm')A 
((mm'))A< 


The  first  two  cases  describe  situations  where  m  is  encrypted  with  a  shared  key  K .  In  the  first  line, 
A  decrypt  a  message  containing  m,  thus  exposing  this  term,  in  the  second  she  builds  such  a  term  for 
export.  The  last  two  cases  are  similar,  except  that  m  is  the  key  itself.  Note  that  in  all  cases,  the  action 
is  known  to  have  been  performed  by  A.  For  this  reason,  there  is  no  need  to  assume  the  key  to  be 
uncompromised.  It  is  a  simple  exercise  to  verify  that  the  proposition  has(X,  k)  holds  in  exactly  the 
three  situations  below,  with  respect  to  all  the  formulas  we  have  derived  in  this  paper: 

1.  X  =  S,  i.e.,  the  server  S  who  generated  k  knows  k. 

2.  X  is  the  observer  of  the  formula,  obviously. 

3.  X  =  A,  the  observer  is  B,  the  key  distribution  protocol  is  a  descendent  of  KD2  (i.e.,  S  sends 
ktoB  cryptographically  embedded  in  the  message  for  A),  and  the  key  KAS  is  assumed  to  be 
uncompromised. 

In  particular,  it  has  never  been  the  case  that  has (B,  k )  from  the  point  of  view  of  A. 

Since  k  is  now  a  shared  secret  between  A  and  B  (supposedly),  the  easiest  way  to  provide  the 
missing  guarantee  is  for  B  to  send  A  a  pre-agreed  message  encrypted  with  k.  Consider  the  following 
protocol  fragment: 

A  B 


where  m  is  arbitrary.  The  two  simple  roles  arc  as  follows: 


enc_to  [A;B,k,m\  =  {k,m:B-+A) 

enc_from[S;  A,  k,  m)  =  (k,m:B^A) 


B  is  unable  to  infer  anything  interesting  from  his  observations  since  he  never  receives  anything  from 
A.  On  the  other  hand,  under  the  assumption  that  k  is  uncompromised,  A  deduces  that  it  is  B  who 
sent  this  message: 

A:  uncompromised(fe,  [A,  B])  {km)  a 
=>  { km)B<  <  {km) a 

Notice  that,  in  this  formula,  the  proposition  has(,4,  k)  now  holds. 

At  this  point,  we  can  simply  use  the  extending  transformation  XT  (which  simply  adds  an  action 
at  the  end  of  a  protocol)  and,  by  a  number  of  applications  of  the  discharging  transformation  DC,  we 
can  augment  NSSKo  and  NSSKfixo  with  a  send  action  intended  for  B  to  confirm  to  A  that  he  knows 
the  key.  The  message  m  can  be  arbitrary,  for  example  A,  B.  The  resulting  run  in  the  case  of  (the 
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shorter)  NSSK  is  as  follows: 


A 

o 

V  71 1 

o 

o 
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n,A,B 

- ^  o 

I<AS  ( n,B,k,KBS  ( A,k ))  \vk 

- o 
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o  ^ - 


B 


o 
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Let  us  call  this  protocol  NSSKi.  A’s  observations  lead  her  to  conclude: 


A  : 


uncompromised(il'j4,s,  [A,  5])  A  honest  S  A 

(Kas  (n,  B,  k,  M))a 


< 


(z 'n)A  <  (n,  A,  B)  a  < 

<  (n,A,B)s  <  ( vk)s  <  (KAS  (n,B,k,KBS  (A,k)))s<  < 
<  (I<AS  (n,B,k,KBS  (A,k))A  < 


(Kbs  (A,  k))A  <  ( KBS(A,k))B  <  (k  (A,  B))b<  <  ( k(A,B))A 


We  have  highlighted  the  additions  with  respect  to  NSSKo  (see  Section  4.1)  by  enclosing  them  in 
boxes.  Recall  that  we  had  omitted  the  then  trailing  (M)a  and  (KBS  (A.  />')). 4  since  they  did  not 
add  substantial  information.  Now  they  clearly  do,  as  they  allow  A  to  infer  that  B  has  received  this 
message  and  originated  k  ( A ,  B).  It  is  easy  to  verify  that  within  this  formula,  has (B,  k )  holds,  which 
achieves  our  goal. 

The  last  addition,  uncompromised(A:,  [A,B]),  deserves  some  discussion.  Clearly,  we  need  to 
know  that  k  is  uncompromised  to  infer  anything  useful  involving  it.  However,  most  formal  systems 
would  derive  this  fact  rather  than  assume  it.  This  may  be  where  the  strict  separation  between  authenti¬ 
cation  and  secrecy  is  most  evident  in  this  work.  Recall  that  our  logical  system  is  just  powerful  enough 
to  reason  about  the  order  of  actions,  the  structure  underlying  authentication.  In  particular  it  does  not 
embed  the  closed-world  assumption,  nor  the  induction  principles  to  reason  about  it.  Deriving  that  k 
must  indeed  be  secret  would  rely  on  such  devices.  We  intend  to  develop  the  secrecy  facet  of  this  logic 
in  future  work.  The  assumption  uncompromised(fc,  [A,  B])  is  an  interface  to  this  future  extension. 

Applying  the  above  extension  to  NSSKfixo  yields  NSSKfixi.  This  protocol  has  then  the  typical 
properties  of  a  key  distribution  protocol:  both  clients  receive  assurance  that  the  key  has  been  generated 
by  the  expected  server,  that  this  key  is  controllably  recent,  and  that  they  both  know  the  key.  However, 
the  actual  NSSK-fix  is  different:  B  encrypts  a  new  nonce  with  k  and  sends  it  to  A,  and  expect  this 
same  nonce  back  from  A,  transformed  in  a  predictable  way.  We  will  now  analyze  what  additional 
properties  are  achieved  by  doing  so.  For  the  sake  of  succinctness,  we  operate  on  NSSKi,  which  differs 
from  the  original  NSSK  in  precisely  the  same  way  as  NSSKfixi  is  different  from  NSSK-fix.  Here  is 
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the  expected  run  of  NSSK: 

A  S  B 


o 


I<AS  ( n,B,k,KBS  ( A,k ))  \vk 


First,  notice  that  having  A  send  something  encrypted  with  k  back  to  B  does  not  produce  any  new 
knowledge  (besides  the  obvious,  i.e.,  that  a  new  message  has  been  transmitted).  It  does  make  the 
hypothesis  that  KAS  was  uncompromised  (which  ultimately  was  the  reason  why  B  could  conclude 
that  A  had  knowledge  of  k)  unnecessary,  but  the  gain  is  rather  slim:  a  compromised  KAS  immediately 
allows  compromising  k.  These  two  propositions  arc  however  distinct  in  our  logic  since  we  never 
derive  an  uncompromised  fact. 

It  should  however  be  observed  that,  from  the  point  of  view  of  B ,  the  last  two  messages  NSSK 
implement  a  challenge-response  exchange:  B  generates  the  nonce  n! ,  sends  it  to  A  encrypted  (with 
k),  and  expected  it  back  from  her  transformed.  By  doing  so,  B  ascertains  that  A  in  indeed  alive  at 
this  particular  point  of  the  protocol.  Note  that  B  could  repeat  this  same  exchange  an  arbitrary  number 
of  times  (each  with  a  new  nonce)  and  obtain  the  same  guarantee:  that  A  was  recently  alive.  If  B's 
challenges  include  a  request  for  a  service  (e.g.,  retrieving  a  file)  and  ,4’s  responses  embed  an  outcome 
for  this  service  (e.g.,  the  file  itself,  or  an  error  message),  this  protocol  implements  a  crude  (and  rather 
lopsided)  single-authentication,  repeated-request  client-server  mechanism:  NSSKo  realizes  the  initial 
authentication  and  key  distribution,  the  added  challenge-response  forms  the  basis  of  each  instance  of  a 
subsequent  client-server  exchange,  protected  by  the  key  obtained  in  the  first  phase.  This  interpretation 
of  NSSK  is  clearly  not  realistic  since  it  implies  that  the  service  provider  (A)  initiates  the  exchange 
while  the  client  (B)  just  gets  to  issues  the  requests  for  service.  However,  we  will  see  in  Section  5 
that  a  nearly  identical  mechanism  is  used  in  Kerberos  to  support  repeated  service  requests  based  on  a 
single  initial  key  distribution. 

In  summary,  our  analysis  shows  that  NSSK-fix  achieves  key  distribution  with  recency  guarantees 
and  key  confirmation  for  both  parties.  NSSK  provides  recency  assurance  only  to  the  initiator.  Our 
work  also  shows  that  the  same  guarantees  arc  also  supported  by  simpler  protocols  that  drop  the  last 
message  and  rely  on  any  pre-arranged  message  instead  of  the  final  nonce.  How  they  stand  now,  both 
NSSK  and  NSSK-fix  have  a  flavor  of  repeated  client-server  protocols  with  the  initiator  and  responder 
roles  inverted. 

5  Derivations  of  Kerberos 

Kerberos  is  a  complex  and  versatile  protocol  that  has  been  the  subject  of  intense  scrutiny  over  the 
years  [15,  16].  In  this  section,  we  will  apply  the  methods  outlined  above  to  derive  the  core  authentica¬ 
tion  functionalities  of  versions  4  and  5  of  this  protocol.  We  concentrate  on  the  basic  key  distribution 
exchange  of  which  each  version  contains  two  instances.  As  a  preparatory  step,  we  formalize  the  use 
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of  timestamps  for  authentication  and  apply  it  to  the  derivation  of  the  Denning-Sacco  protocol,  a  core 
component  of  Kerberos  4. 


5.1  Guaranteeing  Recency  with  Timestamps 

Timestamps  have  a  number  of  applications  in  cryptographic  protocols.  In  this  section,  we  examine 
and  formalize  their  use  for  the  purpose  of  guaranteeing  the  recency  of  an  already  authenticated  mes¬ 
sage.  Consider  a  principal  A  receiving  a  message  KAS  rn  from  an  honest  agent  S:  if  the  key  is 
uncompromised,  A  can  only  deduce  that  S  originated  this  message  in  the  (possibly  distant)  past;  if 
however  S  includes  a  timestamp  t  within  the  encryption  and  sends  KAS(m,  t),  A  can  assess  the  age 
of  the  message  and  reject  it  if  it  falls  outside  of  her  window  of  validity.5 

We  formalize  this  intuition  as  a  transformation  TS.  We  define  it  by  describing  how  it  operates  on 
a  process  P,  how  it  consequently  alters  the  representation  of  the  honesty  of  the  participants,  and  how 
their  knowledge  gets  upgraded. 


Roles  Given  a  roles  p  and  p'  embedding  the  sending  and  receiving  of  KAS  m,  respectively,  the 
transformation  TS  is  described  as  follows: 


TS[  (( Kas  m  :  S  - 

-A))} 

=  ( rt)  ■  {{KAS(m,t)  :  S  - 

-A)) 

TS[  (( Kas  m  :  S  - 

-A))} 

{{KAS{m,t)  ■■  S  - 

-A)) 

Recall  that  the  event  (r  t)  represents  S' s  looking  up  of  his  current  local  time  and  instantiating  t  to  it. 


Honesty  The  honesty  formula  of  both  principals  is  derived  from  the  transformed  process.  In  partic¬ 
ular  S' s  honesty  formula  is  updated  as  follows: 

•  •  •  X  (( I<AS  m:S -»•  A))s<  A--- 
TS(P) 

*V" 

- <  0  t)s  A  (( KAS(m ,  t)  :  S  ->  A))s<  A--- 

ri’s  honesty  is  updated  similarly  (but  it  will  not  play  any  role  in  the  sequel). 


Knowledge  More  interesting  is  the  description  of  how  TS  alters  the  guarantees  that  each  principal 
can  deduce.  Given  the  particular'  format  of  this  transformation  ( S  does  not  receive  a  message  back), 
we  concentrate  on  the  knowledge  accessible  to  A. 

In  the  interest  of  space,  we  elide  the  source  and  destination  directives. 

A:  uncompromised(£;,  [A,  B])  A  ((KAS  raj)  a 

=>-  (( KAsm}}s<  <  ((KAS  m))A 


TS  (P) 

A:  uncompromised(A:,  [A,  B])  A  honest  S  A  ((KAS  (m,t)))A 
(zt)A  <  ( rt)s  <  (( KAS(m,t)))s<  <  (( KAS(m,t)))A 

5This  assessment  takes  into  considerations  clock  skews  between  hosts,  typical  network  delays,  etc. 
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The  top  formula  describes  how  A  can  extend  her  knowledge  after  receiving  K As  m  whenever  the 
original  protocol  guarantees  the  authenticity  of  m:  note  that,  as  long  as  KAS  is  not  compromised,  S 
is  not  required  to  be  honest.  The  bottom  lines  show  the  upgraded  formula.  Recall  that  the  pseudo¬ 
event  (r  t)  represents  the  earliest  point  in  A’s  local  time  where  she  will  accept  the  time  t  as  valid 
i.e.,  “recent  enough”  in  our  context.  Notice  that  it  is  now  important  that  S  is  believed  to  be  honest: 
without  this,  S  could  guess  an  appropriate  value  for  t  rather  than  looking  it  up  from  its  clock. 

We  obtain  this  formula  by  homomorphically  replacing  I\AS  m  with  KAS(m ,  t)  in  the  derivation 
of  the  top  formula.  The  atom  (r  t)s  comes  from  the  upgraded  honesty  axiom.  The  token  (r  t),\ 


represents  A’s  acceptance  of  the  validity  of  t. 

A  S 

We  schematically  represent  this  transformation  by  the  inference  KAS(m) 

rule  at  right.  The  dotted  arrow  links  the  pseudo-event  (r)  to  the  — °  <  ° —  t§ 

beginning  of  the  protocol  in  A's  view.  This  transformation  is  —  t  °  >  ° 

closely  related  to  CA  from  Section  3.2.  KAS(m,t)  \Tt 

o  - o 


5.2  The  Denning-Sacco  Protocol 

The  Denning-Sacco  protocol  [5]  applies  the  transformation  YS  just  described  to  the  basic  key  dis¬ 
tribution  protocol  with  nested  encryption  KDj  where  the  authenticated  message  (to  above)  is  k.  X, 
where  k  is  the  newly  generated  key  and  X  is  either  A  or  B.  S  applies  this  transformation  twice, 
adding  the  same  timestamp  next  to  each  key  distribution  submessage.  As  a  consequence,  by  the  com¬ 
pletion  of  the  protocol,  each  principal  has  the  certainty  that  S  has  generated  k  recently.  As  in  KD^, 
because  of  the  nested  encryption,  B  additionally  knows  that  A  has  seen  k  (but  A  cannot  be  certain 
that  B  ever  receives  k).  This  derivation  is  summarized  as  follows: 

A  S  B 

A,B 

O  - O 

KAS(B,k,KBS  ( A,k ))  \vk 

o  -< - o 

I  KBSk 

o - 

A,B 

O  . >  O  ^ . 

I  vk 

KAS(B,k,t,I<BS(A,k,t))  Yrt 

o  ^ - o 

I  I<BS(A,k,t) 


The  Denning-Sacco  is  therefore  characterized  by  the  following  roles: 

NS  .server  [S']  =  (A,  B  :  A  — *■  S)  ;  (u  k  <g>  r  t)  ; 

{Kas  (B,k,t,KBS  (A,k,t))  :  S  -»•  A) 

NSJclientfA;  S,B\  =  (A,  B  :  A  ->  S)  ;  ( KAS  (B,  k,  t,  M)  :  S  -»•  A)  ; 

(M  :  A  — ►  B) 

NS_rclient[5;  S]  =  ( KBS  (A,  k,  t)  :  A  -r  B) 

The  verification  of  the  timestamp  t  occurs  in  the  implicit  match.  This  is  from  this  operation  that  the 
pseudo-events  r  t  stem. 


—  2TS 

o 


o 
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As  usual,  we  summarize  next  the  information  gained  by  each  principal  as  she  reaches  the  end  of 
her  run.  From  the  sole  observation  of  her  actions  and  the  honesty  of  the  server,  A  can  reconstruct  the 
whole  protocol,  save  for  B's  reception  of  her  last  message: 


A  : 


honest  S'  A  uncompromised(/ij45,  [A,  S])  A 

{A,B)a  <  (Kas(B,  k,  t,  M))a 

'(A,B)a<(A,B)s 

( Zt)A 

<  ( KAS(B,k,fKBS(A,k,t)))s<  <  {Kas(B,  k,  t,  Kbs(A,  k,  t)))A 


{v  k)s 
( Tt)s 


We  have  elided  A’s  final  send  action  as  it  does  not  contribute  added  knowledge.  Note  that  S’ s  gener¬ 
ation  of  k  is  now  bounded  by  r  t,  which  is  under  the  control  of  A. 

B's  conclusions  merge  the  recency  assurance  provided  by  timestamps  with  what  he  could  infer 
by  means  of  KDj,  i.e.,  that  S  has  generated  k  and  that  A  has  seen  it  in  order  to  forward  the  message 
he  receives. 


B  : 


honest  S  A  uncompromised(/iB,s,  [B,  S])  A 
A  uncompromised(iv As ,  [A,  S])  A  (KBS (A,  k,t))B 


( A,B)s 

(rt)B  . 


{vk)s 
.0  Vs. 


<  (Kbs(A,  k,t))A< 


<  (KAS(B,k,t,KBS(A,k,t)))s<  < 
<  (Kbs(A,  k,  t))B 


Denning  and  Sacco  prominently  pointed  out  in  their  original  paper  [5]  that  this  protocol  provides 
full  recency  guarantees  with  a  minimum  number  of  messages. 


5.3  Kerberos  4 

We  will  now  see  that  the  core  authentication  functionalities  of  Kerberos  4  [15]  are  obtained  by  simply 
extending  the  Denning-Sacco  protocol  by  means  of  a  key  confirmation  exchange  similar  to  the  way 
we  obtained  NSSK(-fix)  in  Section  4.3. 


Adding  key  confirmation  In  Section  5.2,  we  observed  that,  by  the  protocol’s  end,  B  is  able  to 
determine  that  A  knows  the  distributed  key  k,  but  that  A  has  no  such  certainty.  In  our  first  step,  we 
simply  use  the  transformation  XT  from  Section  4.3  in  order  for  B  to  acknowledge  the  receipt  of  ,4’s 
last  transmission  by  sending  her  some  (recognizable)  message  m  encrypted  with  The  resulting  run 
is  as  follows: 


A 

o 

o 

I 

o 


A,B 


I<AS(B,k,t,KBS(A,k,t)) 


S 


45-  O 


vk 

T  t 


KBS(A,k,t) 


k  m 

O  -s - 


B 


^  o 


I 


The  corresponding  protocol  is  a  simple  extension  of  DS. 

As  in  the  case  of  NSSKi,  ,4’s  knowledge  is  extended  with  the  certainty  that  B  has  seen  (actually 
used)  k,  under  the  assumption  that  the  master  keys  are  not  compromised.  The  following  formula 
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makes  this  intuition  precise: 


A:  uncompromised(iv As,  [A,  5])  A  honest  S' A 
uncompromised(£;,  [A,B])  A 
{A,B)a  <  (Kas  (B,  k,  t,  M))a  <  (M)a  <  (km) A 


( A,B)s 
(rt)B 


< 


(vk)s 

(rt)s 


<  (KAS(B,  k,  t,  Kbs(A,  k,  t)))s<  < 


<  (Kbs  (A,  k,  t))A  <  (KBS  (A,  k,t))s  <  ( km)B<  <  (km) a 

The  other  remarks  about  NSSKi  and  NSSKfixi  from  Section  4.3  hold  here  as  well. 


Adding  repeated  authentication  Kerberos  was  designed  as  a  repeated  authentication  protocol:  each 
time  A  presents  the  ticket  KBS (A,  k.  t),  B  will  provide  some  predetermined  service  (up  to  an  end- 
date  that  we  can  abstractly  think  of  as  a  function  of  t).  The  protocol  we  just  derived  is  clearly 
inadequate  for  this  purpose  as  anybody  can  replay  the  ticket  KBS(A,  k,  t ).  B  needs  to  authenticate 
that  a  subsequent  request  comes  from  A,  and  assess  that  it  was  made  recently  enough.  Kerberos  4 
realizes  these  two  goals  by  having  A  generate  a  timestamp  t  just  prior  to  issuing  a  new  request, 
and  embedding  into  it  an  authenticator  k  ( A ,  t_,\)  (any  message  mentioning  Ai  and  encrypted  with  k 
would  do).  The  intended  run  of  the  resulting  protocol  is  as  follows: 

A  SB 

A,B 

o - >-  o 

|  vk 

KAS(B,k,t,KBS(A,k,t))  Y  Tt 
o  - o 

TtA\  KBS(A,k,t.),k(AtA) 

o - ^  o 

k  m[tA]  i 

O  -s - O 

where  the  last  message  is  made  dependent  on  t  ,\  (although  Kerberos  does  not  always  enforce  this). 
Technically,  this  protocol  is  obtained  by  first  extending  the  third  message  with  the  token  k  A  (which 
is  completely  redundant  at  this  point)  using  transformation  MC  and  then  applying  the  transformation 
TS  to  it,  and  possibly  pushing  tA  into  m.  Note  that  if  t,\  is  indeed  returned  in  the  last  message,  this 
extension  can  be  seen  as  a  timestamp-based  challenge -response. 

Observe  that,  differently  from  NSSK(-fix),  it  is  the  initiator  of  the  protocol  (the  client.  A)  that 
requests  the  service  provided  by  the  responder  ( B ).  Indeed,  A  generates  the  timestamp  t,\  that  is 
included  in  the  authenticator. 

Kerberos  4  [15]  extends  this  core  protocol  with  numerous  fields  primarily  meant  to  negotiate 
parameters  of  the  resulting  authentication:  added  timestamps,  options  and  flags,  access  control  infor¬ 
mation,  etc.  For  maximum  flexibility,  Kerberos  chains  two  instances  of  the  core  protocol,  by  which 
a  client  (A)  first  obtains  a  master  ticket  (TGT)  which  simplifies  the  issuance  of  tickets  for  individual 
services. 


5.4  Kerberos  5 

As  far  as  authentication  is  concerned,  Kerberos  5,  the  most  recent  version  of  this  protocol  [15,  16], 
differs  from  Kerberos  4  only  by  the  form  of  the  basic  key  distribution  mechanism  it  relies  on:  while 
version  4  was  built  up  from  the  nested  variant  KD2  ,  Kerberos  5  starts  with  the  concatenated  valiant 


37 


KD^.  Given  this  different  starting  point,  the  core  protocol  is  however  derived  by  applying  the  exact 
same  steps  as  in  Kerberos  4.  It  is  interesting  to  examine  them  as  the  conclusions  available  to  the 
various  principals  arc  not  the  same  throughout. 

The  derivation  of  the  analogous  of  the  Denning-Sacco  protocol  is  summarized  as  follows: 


A 

o 

o 

I 

o 


A,B 


Kas  ( B,k ),  Kbs  ( A,k ) 


S 

o 

^vk 

o 


Kbs  (A,k) 


A,B 

o . >  o  ■< 

I  vk 

KAS(B,k,t),KBS{A,k,t)  Y Tt 
o  ^ - o 

\  I<BS(A,k,t) 

o - 


B 


—  2TS 

o 


The  knowledge  derivable  by  A  is  similar  to  the  Denning-Sacco  protocol,  except  that  she  can  never 
be  certain  that  the  encrypted  component  she  receives  corresponds  to  what  S  sent. 


A  : 


honest  S  A  uncompromised^G45,  [A,  S'])  A 

{A,B)a  <  (Kas(B,  k,  t),M)A 

'(A,B)a<(A,B)s 

{zf)A 

<  (KAS(B,k,t),KBS(A,k,t))s<  <  ( KAS(B,k,t),M)A 


{vk)s 

(Tt) 


More  interesting  is  the  knowledge  inferable  by  B:  differently  from  the  Denning-Sacco  proto¬ 
col,  B  cannot  reach  any  conclusion  on  whether  A  ever  saw  the  key  k:  indeed,  the  assumption 
uncompromised(/G AS ,  [A,  S'])  becomes  irrelevant.  B  knows  that  the  server  sent  the  appropriate  mes¬ 
sages  and  that  some  principal  X  forwarded  the  correct  component  to  him.  This  makes  B’s  knowledge 
very  similar  to  ,4’s. 


B  : 


honest  S  A  uncompromised(it  [B,  S])  A  ( KBS(A,k,t))B 
'{A,B)a<(A,B)s 
( Zt)B 

<  (KAS(B,  k,  t),KBS(A,  k,  t))s%  <  (KBS(A,k,t))x  < 

<  (Kbs(A,  k,  t))B 


< 


(v  k)s 
{r  t)s 


< 


Adding  key  confirmation  With  both  A  and  B  unaware  of  whether  its  counterpart  has  seen  k,  each 
party  needs  to  inform  the  other  of  its  knowledge  of  k.  We  rely  on  the  device  already  used  in  Kerberos 
4  to  accomplish  this:  A  will  concatenate  the  component  k  A  (any  message  encrypted  with  k  will  do, 
but  this  happens  to  be  the  core  of  the  Kerberos  authenticator)  as  she  forwards  KBS(A,  k,  t )  to  B.  As 
in  version  4,  B  will  confirm  k  with  a  response  /cm.  for  some  recognizable  m.  We  obtain  the  following 
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exchange: 


A 


S 


B 


A,B 

o - >■  o 

I  uk 

KAS(B,k,t),KBS(A,k,t)  Kt 
o  ^ - o 

\  KBS(A,k,t),kA 

o - >■  o 


This  protocol  fragment  is  extended  to  allow  repeated  authentication  using  k  exactly  as  for  Ker¬ 
beros  4:  A  generates  a  timestamp  t,\  and  includes  it  in  her  authenticator;  B  optionally  returns  Ia  in 
the  last  message. 

This  is  the  authentication  core  of  Kerberos  5.  As  in  its  predecessor,  two  instances  of  this  frag¬ 
ment  arc  chained  together,  and  numerous  fields  add  a  great  deal  of  flexibility  [15,  16].  It  should  be 
noted  that,  in  Kerberos  5,  the  timestamp-based  recency  assessment  (using  t)  is  supplemented  with 
a  nonce-based  guarantee  by  which  A  sends  S  a  nonce  n  with  her  initial  request  and  expects  it  back 
within  Kas(B,  k,  t ).  As  we  saw  in  Section  4.1,  certain  nonce-based  challenge-response  exchanges 
are  alternative  mechanisms  for  ensuring  the  recency  of  an  action.  They  do  not  rely  on  loosely  syn¬ 
chronized  clocks,  but  generally  involve  communication  overhead  (this  is  why  B’ s  recency  guarantees 
do  not  rely  on  nonces). 


References 

[1]  M.  Abadi,  M.  Burrows,  B.  Lampson,  and  G.  Plotkin.  A  calculus  for  access  control  in  distributed 
systems.  ACM  Transactions  on  Programming  Languages  and  Systems ,  21  (4):706— 734,  Septem¬ 
ber  1993. 

[2]  F.  Butler,  I.  Cervesato,  A.  D.  .laggard,  and  A.  Scedrov.  A  Formal  Analysis  of  Some  Properties 
of  Kerberos  5  using  MSR.  In  Proc.  of  the  15th  IEEE  Computer  Security  Foundations  Workshop 
—  CSFW-02,  pages  175-190.  IEEE  Computer  Society  Press,  24-26  June  2002. 

[3]  I.  Cervesato,  C.  Meadows,  and  D.  Pavlovic.  An  Encapsulated  Authentication  Logic  for  Reason¬ 
ing  About  Key  Distribution  Protocol.  In  Eighteenth  Computer  Security  Foundations  Workshop 
—  CSFW-18,  pages  48-61,  Aix-en-Provence,  France,  2005.  IEEE  Computer  Society  Press. 

[4]  A.  Datta,  A.  Derek,  J.  Mitchell,  and  D.  Pavlovic.  A  derivation  system  and  compositional  logic 
for  security  protocols.  Journal  of  Computer  Security,  2004.  to  appeal-. 

[5]  D.  E.  Denning  and  G.  M.  Sacco.  Timestamps  in  key  distribution  protocols.  Communications  of 
the  ACM,  24(8):533— 536,  August  1981. 

[6]  W.  Diffie,  P.  C.  van  Oorschot,  and  M.  J.  Wiener.  Authentication  and  authenticated  key  ex¬ 
changes.  Designs,  Codes,  and  Cryptography,  2:107-125,  1992. 

[7]  N.  Durgin,  J.  Mitchell,  and  D.  Pavlovic.  A  compositional  logic  for  proving  security  properties 
of  protocols.  Journal  of  Computer  Security ,  1 1(4):667— 721,  2003. 

[8]  J.  T.  Fabrega,  J.  Herzog,  and  J.  Guttman.  Strand  spaces. 


39 


[9]  B.  Lampson,  M.  Abadi,  M.  Burrows,  and  E.  Wobber.  Authentication  in  distributed  systems: 
theory  and  practice.  ACM  Trans,  on  Comput.  Syst.,  10(4):265-310,  November  1992. 

[10]  G.  Lowe.  A  herarchy  of  authentication  specifications.  In  Proc.  10th  IEEE  Computer  Security 
Foundations  Workshop ,  pages  31-43,  Rockport,  MA,  1997.  IEEE  Computer  Society  Press. 

[11]  C.  Meadows  and  D.  Pavlovic.  Deriving,  attacking  and  defending  the  gdoi  protocol.  In  Computer 
Security  —  ESORICS  2004,  volume  3193  of  Lecture  Notes  in  Computer  Science,  pages  33-53, 
Sophia-Antipolis,  France,  September  2004.  Springer- Verlag. 

[12]  A.  C.  Myers  and  B.  Liskov.  Protecting  privacy  using  the  decentralized  label  model.  ACM 
Transactions  on  Software  Engineering  and  Methodology,  9(4):410-442,  October  2000. 

[13]  R.  M.  Needham  and  M.  D.  Schroeder.  Using  encryption  for  authentication  in  large  networks  of 
computers.  Communications  of  the  ACM,  21(12):993-999,  December  1978. 

[14]  R.  M.  Needham  and  M.  D.  Schroeder.  Authentication  revisited.  ACM  Operating  Systems  Re¬ 
view,  21(1):7,  January  1987. 

[15]  B.  C.  Neuman  and  T.  Ts’o.  Kerberos:  An  Authentication  Service  for  Computer  Networks.  IEEE 
Communications,  32(9):33— 38,  September  1994. 

[16]  C.  Neuman,  J.  Kohl,  T.  Ts’o,  T.  Yu,  S.  Hartman,  and  K.  Raeburn.  The  Kerberos  Network 
Authentication  Service  (V5),  September  7  2004.  Internet  draft,  expires  7  March  2005. 

[17]  S.  Schneider.  Verifying  Authentication  Protocols  in  CSP.  IEEE  Transactions  on  Software  En¬ 
gineering,  24(9): 74 1-75  8,  1998. 

[18]  J.  G.  Steiner,  C.  Neuman,  and  J.  I.  Schiller.  Kerberos:  An  Authentication  Service  for  Open 
Network  Systems.  In  Proceedings  of  the  Winter  1988  Usenix  Conference,  1998. 

[19]  F.  J.  Thayer  Fabrega,  J.  Herzog,  and  J.  D.  Guttman.  Honest  ideals  on  strand  spaces.  In  Proceed¬ 
ings,  1998  Computer  Security  Foundations  Workshop,  1998. 

A  Relays  and  the  equivalence  of  runs 

Two  processes  should  be  considered  indistinguishable  if  they  have  the  same  executable  runs.6  But  for 
processes  that  run  on  a  network  with  routers  and  relays,  a  run  where  (x  :  A  — ►  B)b  and  (t  :  A  —>  B)  a 
interact  directly,  i.e.  y/(x  :  A  — ►  B)b  =  (t  :  A  — >  B)  .\  is  indistinguishable  from  the  runs  where  of 
these  two  actions  interact  through  any  number  of  relays  in  the  form  (x  :  Y  — >  Z)c’,  {x  :  Y  — >  Z)c, 
so  that  (x  \  A  —>  B)  b  =  (x  :  Y  — >  Z)c  and  yj (x  :  Y  — >  Z)c  =  (t  :  A  — ►  B)a- 
The  consequence  of  this  is  that  the  process 


(t:  S  - 

+  A)s  \ 

(  (x:  S  - 

A) A 

<g>  : 

;  ® 

(u  :  S  - 

-  B)s  J 

\(x:S- 

+  B)b 

f’A  finer  equivalence  would  also  require  that  their  non-executable  runs  fail  in  the  same  ways.  The  whole  linear-time 
branching-time  spectrum  of  concurrent  systems  opens  up. 
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can  be  reasonably  viewed  as  equivalent  with 


(x:S^A)a-  (y:S^B)A-  (y  :  S 
{x  :  S  — >  £)# 

By  bundling  the  two  interactions  between  S'  and  ,4,  ,  we  get  the  process 

(x,  y:S  -»•  A)  a  ;  {y  :  S  B)  A 


(t,u:  S  -»•  A)  s  ; 


(x  :  S  -»•  B) 


B 


5), 


which  is  still  equivalent  with  the  ones  above,  but  one  interaction  has  been  moved  from  S  to  A.  This 
explains  the  transformation 
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